Network Security Platform 8.1 IPS Administration Guide

Network Security Platform 8.1 IPS Administration Guide
IPS Administration Guide
Revision A
McAfee Network Security Platform 8.1
COPYRIGHT
Copyright © 2014 McAfee, Inc. Do not copy without permission.
TRADEMARK ATTRIBUTIONS
McAfee, the McAfee logo, McAfee Active Protection, McAfee DeepSAFE, ePolicy Orchestrator, McAfee ePO, McAfee EMM, Foundscore, Foundstone, Policy
Lab, McAfee QuickClean, Safe Eyes, McAfee SECURE, SecureOS, McAfee Shredder, SiteAdvisor, McAfee Stinger, McAfee Total Protection, TrustedSource,
VirusScan, WaveSecure are trademarks or registered trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other
names and brands may be claimed as the property of others.
Product and feature names and descriptions are subject to change without notice. Please visit mcafee.com for the most current products and features.
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 ACCOMPANY 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 WEBSITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOU DO NOT AGREE TO ALL OF THE TERMS SET
FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF APPLICABLE, YOU MAY RETURN THE PRODUCT TO MCAFEE OR THE PLACE OF
PURCHASE FOR A FULL REFUND.
2
McAfee Network Security Platform 8.1
IPS Administration Guide
Contents
Preface
15
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Find product documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
15
16
Intrusion prevention and Network Security Platform
basics
1
Network security and McAfee Network Security Platform
19
Network security threats and trends . . . . . . . . . . . . . . . . . . . . . . . . . .
Who are you up against . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contributing factors to security threats . . . . . . . . . . . . . . . . . . . . . .
What are you up against? . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fortifying your network using McAfee Network Security Platform . . . . . . . . . . . . . . .
What are attacks and intrusions? . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Network Security Platform protects your network . . . . . . . . . . . . . . . . . . .
2
Network Security Platform Basics
20
20
21
22
24
25
25
31
Network Security Platform overview . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Security Platform components . . . . . . . . . . . . . . . . . . . . .
31
31
Deploying the Sensors for Next Generation IPS and IDS
3
Network Security Platform deployment - an overview
41
Decide where to deploy Sensors and in what operating mode . . . . . . . . . . . . . . . .
Review of pre-deployment considerations . . . . . . . . . . . . . . . . . . . . .
Sensor deployment modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flexible deployment options . . . . . . . . . . . . . . . . . . . . . . . . . .
Full-duplex and half-duplex monitoring . . . . . . . . . . . . . . . . . . . . . .
SPAN port and hub monitoring . . . . . . . . . . . . . . . . . . . . . . . . .
Deployment of Sensors in tap mode . . . . . . . . . . . . . . . . . . . . . . .
Deployment of Sensors in in-line mode . . . . . . . . . . . . . . . . . . . . . .
High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface groups (port clusters) . . . . . . . . . . . . . . . . . . . . . . . . .
Managing interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create sub-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to plan your IPS deployment . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deployment scenario for beginners . . . . . . . . . . . . . . . . . . . . . . .
Deployment scenario for intermediate users . . . . . . . . . . . . . . . . . . . .
Deployment scenario for advanced users . . . . . . . . . . . . . . . . . . . . .
Establish Sensor-to-Manager communication . . . . . . . . . . . . . . . . . . . . . .
Configure your deployment using the Manager . . . . . . . . . . . . . . . . . . . . . .
View and work with data generated by Network Security Platform . . . . . . . . . . . . . .
McAfee Network Security Platform 8.1
42
42
47
47
48
49
50
53
56
58
60
64
65
65
66
67
67
68
69
IPS Administration Guide
3
Contents
Tune your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Update your signatures and software . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4
Configuring the monitoring and response ports of a Sensor
73
Configuration of device monitoring and response ports . . . . . . . . . . . . . . . . . . . 73
Ports for I-Series devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Ports for M-series devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Ports for NS-series Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Monitoring Port details . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Port color key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Hardware for monitoring ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Configuration of monitoring ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Configure ports for I-Series devices . . . . . . . . . . . . . . . . . . . . . . . 84
Configuration of ports for M-series devices . . . . . . . . . . . . . . . . . . . .
88
Configuration of ports for NS-series devices . . . . . . . . . . . . . . . . . . . . 92
Configuration of gigabit ethernet in-line fail-open status . . . . . . . . . . . . . . . 97
Change a monitoring port from single port to a port pair mode . . . . . . . . . . . . 101
Change a monitoring interface from external tap to in-line (and vice versa) . . . . . .
101
Change from internal tap mode to in-line fail-close mode for fast ethernet monitoring ports
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
Configure response ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
View management port settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5
Deployment of Sensors in inline mode
105
Benefits of running inline mode . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inline deployment walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determine your high availability strategy . . . . . . . . . . . . . . . . . . . . . . . .
Failover or high availability . . . . . . . . . . . . . . . . . . . . . . . . . .
Fail-open or fail-closed functionality . . . . . . . . . . . . . . . . . . . . . . .
Setting up the Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to connect the fast ethernet monitoring ports . . . . . . . . . . . . . . . . .
How to connect the gigabit ethernet monitoring ports . . . . . . . . . . . . . . .
Failover pair cable connections . . . . . . . . . . . . . . . . . . . . . . . . .
How to configure the Sensor monitoring ports . . . . . . . . . . . . . . . . . .
Failover — Configuration of two Sensors in inline mode . . . . . . . . . . . . . . . . . .
Creating a failover pair . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
How to configure Sensors for high availability
115
Network Security Platform fail-over architecture . . . . . . . . . . . . . . . . . . . . .
Sensor fail-over implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to understand the current network topology . . . . . . . . . . . . . . . . . . . .
Two paths - Active/passive . . . . . . . . . . . . . . . . . . . . . . . . . .
Two paths - Active/active . . . . . . . . . . . . . . . . . . . . . . . . . . .
A single path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimal Sensor location determination . . . . . . . . . . . . . . . . . . . . . . . .
Redundant Sensors on a single path . . . . . . . . . . . . . . . . . . . . . .
How to prevent duplicate alerts . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration of the ports on each Sensor . . . . . . . . . . . . . . . . . . . . . . .
Potential pitfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A note on fail open functionality for GE ports . . . . . . . . . . . . . . . . . . .
A caution about active-passive failover . . . . . . . . . . . . . . . . . . . . .
How dongles work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation of the Sensors physically . . . . . . . . . . . . . . . . . . . . . . . . .
Reality check — Asymmetric routing . . . . . . . . . . . . . . . . . . . . . .
How to define the Network Security Platform fail-over pair . . . . . . . . . . . . . . . .
4
McAfee Network Security Platform 8.1
106
106
107
107
107
108
109
109
109
110
112
112
115
116
116
116
117
117
117
119
120
120
120
122
122
122
123
126
129
129
IPS Administration Guide
Contents
Connecting heartbeat cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBIC cable connections . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cabling guidelines and examples . . . . . . . . . . . . . . . . . . . . . . . .
TX GBICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cable failover through a network device . . . . . . . . . . . . . . . . . . . . .
Verification of the fail-over configuration . . . . . . . . . . . . . . . . . . . . . . . .
Sensor communication confirmation . . . . . . . . . . . . . . . . . . . . . .
Test failover setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network scenarios for Sensor high availability . . . . . . . . . . . . . . . . . . . . . .
I-4010 Sensor in load balanced configuration . . . . . . . . . . . . . . . . . . .
I-4010 Sensor in active/active HA mode . . . . . . . . . . . . . . . . . . . . .
I-4010 Sensor in active/passive HA mode . . . . . . . . . . . . . . . . . . . .
7
Virtual IPS Sensor deployment
137
Virtual Sensors - advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual IPS Sensor models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for deploying Virtual Sensors . . . . . . . . . . . . . . . . . . . . . .
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported modes for Virtual Sensor . . . . . . . . . . . . . . . . . . . . . .
Features supported by a Virtual Sensor . . . . . . . . . . . . . . . . . . . . .
Features not supported by Virtual Sensors . . . . . . . . . . . . . . . . . . . .
Deploying Virtual Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Virtual Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deployment scenarios for Virtual Sensors . . . . . . . . . . . . . . . . . . . .
Verify the deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generate the Virtual IPS Sensor License Compliance report . . . . . . . . . . . . . . . .
8
How to understand virtualization
Troubleshooting
Upload diagnostics trace . . . . . . . . . . . . . . . .
How to verify if traffic is flowing through the Sensor . . . . .
Verification to check whether failover pair creation is successful
show . . . . . . . . . . . . . . . . . . . . .
McAfee Network Security Platform 8.1
139
139
140
141
141
141
143
144
144
164
199
199
201
Network scenario without virtualization . . . . . . . . . . . . . . . . . . . . . . . .
Virtual IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sub-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Policy inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DoS policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port versus interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network scenario with virtualization . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dedicated interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VLAN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bridge VLAN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CIDR interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How policies are applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inline mode and dedicated interface . . . . . . . . . . . . . . . . . . . . . .
Sub-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SPAN or tap mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common use of VLAN, bridge VLAN, and CIDR interfaces . . . . . . . . . . . . . . . . .
Interface, VLAN, and CIDR limits . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
130
131
131
132
133
133
133
134
134
135
135
136
136
201
202
202
203
203
204
205
205
205
206
207
207
209
216
223
223
223
224
224
225
226
227
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. .
. .
. .
. .
227
228
228
228
IPS Administration Guide
5
Contents
status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
show failover-status . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
downloadstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to replace a Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to replace a failed Sensor . . . . . . . . . . . . . . . . . . . . . . . . .
Maintenance of Sensor certificate information when replacing a Sensor . . . . . . . .
Delete a Sensor from the Manager . . . . . . . . . . . . . . . . . . . . . . .
Add a deleted Sensor back to the Manager . . . . . . . . . . . . . . . . . . . .
228
229
229
229
229
230
231
231
Configuring Network Security Platform for intrusion
prevention
10
IPS policies
235
Network Security Platform policies . . . . . . . . . . . . . . . . . . . . . . . . . .
How policies are applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inline mode and dedicated interface . . . . . . . . . . . . . . . . . . . . . .
Sub-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SPAN or tap mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Components of an IPS policy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classification of attack definitions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attack categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attack subcategories . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protection categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Severity level calculation of attacks . . . . . . . . . . . . . . . . . . . . . . . . . .
Attack categories and severity range . . . . . . . . . . . . . . . . . . . . . .
Pre-configured rule sets and policies . . . . . . . . . . . . . . . . . . . . . . . . .
Preconfigured policies . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preconfigured Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration of policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tune your policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attack Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
False positives and noise . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to block attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Methods for blocking attacks . . . . . . . . . . . . . . . . . . . . . . . . .
How to block exploit traffic . . . . . . . . . . . . . . . . . . . . . . . . . .
Use of traffic normalization . . . . . . . . . . . . . . . . . . . . . . . . . .
How to block based on configured TCP/IP settings . . . . . . . . . . . . . . . . .
How to block IP-spoofed packets . . . . . . . . . . . . . . . . . . . . . . . .
How to respond to detected attacks . . . . . . . . . . . . . . . . . . . . . . . . . .
Response management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
IPS Policy user interfaces
Rule Sets page . . . . . .
Definitions tab . . .
Rules tab . . . . .
IPS Policies Page . . . . .
Properties tab . . .
Attack Definitions tab
12
.
.
.
.
.
.
261
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
IPS Policies page .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Working with IPS policies
How to manage rule sets? . . . .
Create a rule set . . . . .
How to manage IPS policies . . . .
Add an IPS policy . . . . .
Assign an IPS policy from the
6
235
236
236
236
237
237
238
239
239
240
244
245
245
246
247
249
250
250
251
253
254
254
254
255
256
256
257
257
McAfee Network Security Platform 8.1
261
263
263
264
265
265
271
271
272
277
277
281
IPS Administration Guide
Contents
Configuration of attack compilation . . . . . . . . . . . . . . . . . . . . . . .
Use Bulk Edit for IPS policy . . . . . . . . . . . . . . . . . . . . . . . . . .
Add comments for an attack . . . . . . . . . . . . . . . . . . . . . . . . . .
Customize attacks across policies . . . . . . . . . . . . . . . . . . . . . . .
Attack descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to export and import policies . . . . . . . . . . . . . . . . . . . . . . . . . .
Export policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to import and compare policies? . . . . . . . . . . . . . . . . . . . . . .
Assign IPS and reconnaissance policies at the admin-domain level . . . . . . . . . . . . .
Assign an IPS policy from the IPS Policies page . . . . . . . . . . . . . . . . . .
Assign reconnaissance policies to Sensors from the Reconnaissance Policies page . . . .
Assign policies for a Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assign IPS policies to interfaces and subinterfaces . . . . . . . . . . . . . . . . . . . .
Customize Local IPS Policy . . . . . . . . . . . . . . . . . . . . . . . . . .
Scenario: Apply different policies to multiple subinterfaces . . . . . . . . . . . . .
Protection profile management at the interface level . . . . . . . . . . . . . . . . . . .
Protection options at interface level . . . . . . . . . . . . . . . . . . . . . .
The IPS Sensor interface node . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration of general interface settings . . . . . . . . . . . . . . . . . . . .
Deploy pending changes to a device . . . . . . . . . . . . . . . . . . . . . . . . .
Import a Sensor configuration file . . . . . . . . . . . . . . . . . . . . . . . . . .
Export the Sensor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alert notification options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to view alert notification details . . . . . . . . . . . . . . . . . . . . . .
Forward alerts to an SNMP server . . . . . . . . . . . . . . . . . . . . . . .
Syslog notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure email or pager alert notifications . . . . . . . . . . . . . . . . . . . .
Enable alert notification by script . . . . . . . . . . . . . . . . . . . . . . . .
13
Device Profiling and Alert Relevance
343
Device Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passive Device Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Profiling using McAfee ePolicy Orchestrator . . . . . . . . . . . . . . . . .
Display of device profiles in the Manager . . . . . . . . . . . . . . . . . . . . .
Troubleshooting for device profiling . . . . . . . . . . . . . . . . . . . . . . .
Alert relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The relevance scoring algorithm . . . . . . . . . . . . . . . . . . . . . . . .
Special circumstances . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enable alert relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Advanced Malware Policies
Advanced botnet detection
369
372
374
382
384
385
387
387
389
How the Advanced Botnet Detection Framework works . . . . . . . . . . . . . . . . . .
0-day botnet detection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Known botnet detection . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure Advanced Botnet Detection from the admin domain . . . . . . . . . . . . . . .
Configure Advanced Botnet Detection at the interface level . . . . . . . . . . . . . . . .
McAfee Network Security Platform 8.1
343
344
347
349
352
352
354
359
359
361
Add an Advanced Malware policy . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Advanced Malware policies . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyze Malware Detections . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View the McAfee Advanced Threat Defense specific details for a detected malware . . . .
Manager reports for malware detections . . . . . . . . . . . . . . . . . . . . .
Archive malware files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add hash values to the whitelist . . . . . . . . . . . . . . . . . . . . . . . .
Add hash values to the blacklist . . . . . . . . . . . . . . . . . . . . . . . .
15
284
284
287
291
298
299
299
300
303
303
307
308
310
311
312
313
315
315
316
317
319
320
320
321
321
324
339
340
389
390
391
392
393
IPS Administration Guide
7
Contents
Bot Command and Control server activity detection . . . . . . . . . . . . . . . . . . . 394
Manage Botnet Detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Analyze Active Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
16
Denial-of-Service attacks
405
What is a Denial-of-Service attack? . . . . . . . . . . . . . . . . . . . . . . . . . .
What is a Distributed Denial-of-Service attack? . . . . . . . . . . . . . . . . . . . . .
Evolution of Denial-of-Service attacks . . . . . . . . . . . . . . . . . . . . . . . . .
How a Denial-of-Service attack works . . . . . . . . . . . . . . . . . . . . . . . . .
DoS attacks defended against by Network Security Platform . . . . . . . . . . . . . . . .
Volume-based Denial-of-Service attacks . . . . . . . . . . . . . . . . . . . . .
Vulnerability-based DoS attacks . . . . . . . . . . . . . . . . . . . . . . . .
Distributed Denial-of-Service attack tools . . . . . . . . . . . . . . . . . . . .
DoS attack detection mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .
Volume-based DoS attack detection . . . . . . . . . . . . . . . . . . . . . .
Exploit-based DoS attack detection . . . . . . . . . . . . . . . . . . . . . . .
Layer 7 DoS protection for web servers . . . . . . . . . . . . . . . . . . . . . . . .
Web server protection settings . . . . . . . . . . . . . . . . . . . . . . . . .
Web client protection settings . . . . . . . . . . . . . . . . . . . . . . . . .
Configure Web Server - Denial-of-Service Protection at the admin domain node . . . . .
Configure Web Server - Denial-of-Service Protection at the interface level . . . . . . .
Manage DoS attack definitions for an interface and a subinterface . . . . . . . . . . . . .
Customize DoS attack definitions for an interface or subinterface . . . . . . . . . . .
Customized DoS policy in a network . . . . . . . . . . . . . . . . . . . . . .
Denial-of-Service profile advanced scanning . . . . . . . . . . . . . . . . . . . . . .
What is a DoS profile? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View the DoS profiles of a Sensor . . . . . . . . . . . . . . . . . . . . . . .
DoS data management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DoS filter management . . . . . . . . . . . . . . . . . . . . . . . . . . .
DoS attack prevention methods . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistical anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Advanced malware botnet detection . . . . . . . . . . . . . . . . . . . . . . .
SYN cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stateful TCP engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DNS protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection limiting with McAfee GTI integration enabled . . . . . . . . . . . . . .
Custom Reconnaissance Attack Definition . . . . . . . . . . . . . . . . . . . .
Managing DoS-related actions using command line interface . . . . . . . . . . . . . . . .
Set Denial-of-Service prevention severity . . . . . . . . . . . . . . . . . . . .
Block DoS attack traffic from a specific host . . . . . . . . . . . . . . . . . . .
Viewing a DoS profile . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing DoS prevention severity . . . . . . . . . . . . . . . . . . . . . . . .
Connection Limiting policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Connection Limiting policies work . . . . . . . . . . . . . . . . . . . . .
Considerations for Connection Limiting policies . . . . . . . . . . . . . . . . . .
Components of Connection Limiting rules . . . . . . . . . . . . . . . . . . . .
Comparison between Protocol and McAfee GTI rule type . . . . . . . . . . . . . .
Considerations for rule types . . . . . . . . . . . . . . . . . . . . . . . . .
Effects of X-Forwarded-For (XFF) on connection limiting . . . . . . . . . . . . . . .
Create, clone, and modify Connection Limiting policies . . . . . . . . . . . . . . .
Assign a Connection Limiting policy to an interface or subinterface . . . . . . . . . .
Alert for Connection Limiting policies . . . . . . . . . . . . . . . . . . . . . .
CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
McAfee Network Security Platform 8.1
405
406
406
407
407
408
413
413
413
414
429
431
432
433
434
435
436
436
443
445
445
445
448
451
452
454
455
456
456
456
458
458
458
459
459
460
460
460
462
462
463
464
465
466
467
468
468
473
474
475
IPS Administration Guide
Contents
17
Inspection of SSL traffic
477
Supported web servers and cipher suites for SSL inspection . . . . . . . . . . . . . . . .
Unsupported SSL functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . .
Steps involved in configuring SSL decryption . . . . . . . . . . . . . . . . . . . . . .
Enable SSL decryption on a Sensor . . . . . . . . . . . . . . . . . . . . . . .
Management of the imported SSL keys of a device . . . . . . . . . . . . . . . . .
SSL best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL only traffic — throughput: I-series Sensors . . . . . . . . . . . . . . . . . .
SSL only traffic — throughput: I-series and M-series Sensors . . . . . . . . . . . .
SSL traffic mixed with HTTP 1.1 traffic: I-series Sensors . . . . . . . . . . . . . .
SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors . . . . . . . . . . . . . .
SSL only traffic - throughput: NS-series Sensors . . . . . . . . . . . . . . . . .
SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors . . . . . . . . . . . . . .
18
How McAfee identifies applications?
487
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applications-related terminologies . . . . . . . . . . . . . . . . . . . . . . . . . .
How application identification works? . . . . . . . . . . . . . . . . . . . . . . . . .
19
477
478
478
479
480
482
482
483
483
484
485
485
Working with Reconnaissance policies
488
488
489
491
Reconnaissance policies management . . . . . . . . . . . . . . . . . . . . . . . . . 491
Add a Reconnaissance policy . . . . . . . . . . . . . . . . . . . . . . . . .
493
Assign reconnaissance policies to Sensors from the Reconnaissance Policies page . . . . 497
20
Firewall policies
499
Types of Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Components of Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-level steps for configuring Firewall policies . . . . . . . . . . . . . . . . . . . . .
Application identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applications-related terminologies . . . . . . . . . . . . . . . . . . . . . . .
How application identification works? . . . . . . . . . . . . . . . . . . . . . .
User-based access rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-level steps for implementing user-based Firewall and QoS rules . . . . . . . . .
How user-based access rules work . . . . . . . . . . . . . . . . . . . . . . .
Require Authentication access rule and how it works . . . . . . . . . . . . . . . .
Considerations for access rules . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting user-based access rules . . . . . . . . . . . . . . . . . . . . .
Configure Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage rule objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure the DNS server details . . . . . . . . . . . . . . . . . . . . . . . .
Configure the time zone . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional configurations for Kerberos snooping . . . . . . . . . . . . . . . . . .
Configure the Guest Portal . . . . . . . . . . . . . . . . . . . . . . . . . .
Specify IP details for monitoring ports . . . . . . . . . . . . . . . . . . . . . .
Management of Firewall policies . . . . . . . . . . . . . . . . . . . . . . . .
Using stateless access rules to save Sensor resources . . . . . . . . . . . . . . . . . .
Stateless access rules and scanning exceptions . . . . . . . . . . . . . . . . . .
Configure stateless access rules . . . . . . . . . . . . . . . . . . . . . . . .
How to view the details of matched traffic . . . . . . . . . . . . . . . . . . . . . . .
Enable rule match notification . . . . . . . . . . . . . . . . . . . . . . . . .
Run the Firewall Policy Definitions configuration report . . . . . . . . . . . . . . .
Firewall-related capacity values . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing effective Firewall rules . . . . . . . . . . . . . . . . . . . . . . . . .
21
Quality of Service policies
571
Components of the QoS feature . . . . . . . . . . . . . . . . . . . . . . . . . . .
McAfee Network Security Platform 8.1
500
501
504
507
507
509
510
512
514
516
518
519
520
520
531
533
534
537
541
543
558
559
560
562
563
567
567
569
573
IPS Administration Guide
9
Contents
Components of a QoS policy . . . . . . . . . . . . . . . . . . . . . . . . . .
Rate Limiting profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How QoS works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Considerations regarding rate limiting . . . . . . . . . . . . . . . . . . . . . . . .
Rate limiting of application protocols using SSL . . . . . . . . . . . . . . . . . .
Port level limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage rule objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure the DNS server details . . . . . . . . . . . . . . . . . . . . . . . .
Configure the time zone . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Rate Limiting profiles . . . . . . . . . . . . . . . . . . . . . . . . .
Create a QoS policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View the effect of the applied Rate Limiting rules . . . . . . . . . . . . . . . . . . . .
Network scenarios for QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
How to create exceptions for an applied IPS policy
617
Configure alert suppression with packet log response . . . . . . . . . . . . . . . . . . .
Set Global Auto Acknowledgement options for RFSB and non-RFSB attacks . . . . . . . . . .
How to manage exception objects? . . . . . . . . . . . . . . . . . . . . . . . . . .
How to use the exception objects editor? . . . . . . . . . . . . . . . . . . . .
Management of rule objects . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment of alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exception Object assignments . . . . . . . . . . . . . . . . . . . . . . . . .
Exception creation interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create and assign exception objects . . . . . . . . . . . . . . . . . . . . . .
Create and assign firewall policies . . . . . . . . . . . . . . . . . . . . . . .
Disable an attack definition . . . . . . . . . . . . . . . . . . . . . . . . . .
Stateless Scanning Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add a Stateless Scanning Exception . . . . . . . . . . . . . . . . . . . . . . .
Enable the Scanning Exceptions . . . . . . . . . . . . . . . . . . . . . . . .
Generate Scanning Exception reports . . . . . . . . . . . . . . . . . . . . . .
Simulated Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure Simulated Blocking at the interface level . . . . . . . . . . . . . . . .
23
Protecting web applications servers and inspecting HTTP traffic
Quarantining hosts
McAfee Network Security Platform 8.1
649
650
658
658
660
661
661
663
How Quarantine works? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-level steps for configuring Quarantine . . . . . . . . . . . . . . . . . . . . . . .
Considerations for Quarantine rule creation . . . . . . . . . . . . . . . . . . . . . . .
Procedures for configuring Quarantine . . . . . . . . . . . . . . . . . . . . . . . . .
Manage rule objects for Quarantine . . . . . . . . . . . . . . . . . . . . . . .
Forward quarantine zone access rule matches to a syslog server . . . . . . . . . . .
Manage Quarantine Zones . . . . . . . . . . . . . . . . . . . . . . . . . .
Customize Quarantine browser message . . . . . . . . . . . . . . . . . . . . .
Specify the Remediation portal details . . . . . . . . . . . . . . . . . . . . .
Quarantine settings for an admin domain . . . . . . . . . . . . . . . . . . . .
Quarantine settings at Sensor level . . . . . . . . . . . . . . . . . . . . . . .
Quarantine configuration in the policies . . . . . . . . . . . . . . . . . . . . .
10
617
620
620
621
626
632
637
641
641
643
644
645
645
646
646
647
647
649
Protecting your web application servers . . . . . . . . . . . . . . . . . . . . . . . .
Implementing the Heuristic Web Application Server Protection option . . . . . . . . .
HTTP response scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure HTTP response scanning at the interface level . . . . . . . . . . . . . .
Inspecting X-Forwarder-For header information . . . . . . . . . . . . . . . . . . . . .
Configure X-Forwarded-For (XFF) Header Parsing . . . . . . . . . . . . . . . . .
View original source IP in the Threat Analyzer . . . . . . . . . . . . . . . . . . .
24
573
576
577
582
582
583
584
584
596
597
598
604
611
614
664
665
666
667
667
676
681
684
685
685
688
692
IPS Administration Guide
Contents
Manually quarantine hosts from the Threat Analyzer . . . . . . . . . . . . . . . .
Browser redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Quarantining virtual machines using third-party applications
707
High-level configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How traffic between virtual machines is inspected? . . . . . . . . . . . . . . . . . . . .
Considerations and requirements for inspecting VM traffic . . . . . . . . . . . . . . . . .
Configure port-mirroring on the vSphere Distributed Switch . . . . . . . . . . . . . . . .
Inspect traffic using VMware applications . . . . . . . . . . . . . . . . . . . . . . .
Inspect traffic using Reflex applications . . . . . . . . . . . . . . . . . . . . . . . .
Install Reflex VMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Install vTrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure the IDS Redirector . . . . . . . . . . . . . . . . . . . . . . . . .
Enable Quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enable APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure the VM-Aware interface in the Manager . . . . . . . . . . . . . . . . . . . .
Configure the details of the VMware applications . . . . . . . . . . . . . . . . .
Configure the details of the Reflex VMC . . . . . . . . . . . . . . . . . . . . .
How to view alerts related to VM traffic . . . . . . . . . . . . . . . . . . . . . . . .
Check the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Sensors and VM-Aware ports . . . . . . . . . . . . . . . . . . . . . . . . .
26
Inspection of special traffic types
Advanced Traffic Inspection
733
733
735
735
736
736
738
738
739
741
Configure Advanced Traffic Inspection at the interface or sub-interface level . . . . . . . . .
28
708
709
710
711
714
718
718
719
719
720
720
721
721
724
726
727
729
729
733
IPS on double VLAN tagged traffic . . . . . . . . . . . . . . . . . . . . . . . . . .
How VLAN tagging works? . . . . . . . . . . . . . . . . . . . . . . . . . .
Scenario for double VLAN tagging . . . . . . . . . . . . . . . . . . . . . . .
How Network Security Platform handles double VLAN tagged traffic? . . . . . . . . .
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tunneled traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jumbo frame parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sensor functions with jumbo frame support . . . . . . . . . . . . . . . . . . .
Enable jumbo frame parsing . . . . . . . . . . . . . . . . . . . . . . . . . .
27
697
702
Layer 7 data collection
741
745
Enable Layer 7 Data Collection for an interface or subinterface . . . . . . . . . . . . . . . 745
CLI command for Layer 7 Data Collection . . . . . . . . . . . . . . . . . . . . . . . 748
Sensor performance with Layer 7 Data Collection . . . . . . . . . . . . . . . . . . . . 749
29
Exporting Layer 7 data to NTBA appliances
753
Configure the monitoring ports to export L7 data . . . . . . . . . . . . . . . . . . . .
Define the Layer 7 data to be exported . . . . . . . . . . . . . . . . . . . . . . . .
30
IP Reputation
753
753
755
Configure IP Reputation for an admin domain . . . . . . . . . . . . . . . . . . . . . . 755
Configure IP Reputation for an interface . . . . . . . . . . . . . . . . . . . . . . . . 757
31
Using a Sensor to capture data packets
761
Capture of data packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure packet capture settings in port mode . . . . . . . . . . . . . . . . . .
Configure packet capture settings in file mode . . . . . . . . . . . . . . . . . .
Configure and manage packet capture rules . . . . . . . . . . . . . . . . . . .
View packet capture status . . . . . . . . . . . . . . . . . . . . . . . . . .
McAfee Network Security Platform 8.1
761
763
764
766
767
IPS Administration Guide
11
Contents
Manage captured files . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
IP spoofing detection
769
Enable IP address spoofing detection . . . . . . . . . . . . . . . . . . . . . . . . .
Create a Dashboard to view the count of dropped IP-spoofed packets . . . . . . . . . . . .
33
768
Enable layer 2 settings
769
770
773
Detection of ARP spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Exit layer 2 pass-through mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
34
Configure IP Settings
777
35
Configure TCP Settings
781
How to counter SYN floods with SYN cookies . . . . . . . . . . . . . . . . . . . . . .
Asymmetric traffic handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Configuring non-standard ports
787
Define the non-standard ports at the domain and Sensor levels . . . . . . . . . . . . . .
Edit a non-standard port entry . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
783
784
Network forensics
787
789
791
Enable Network Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Analyze Network Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Managing the Sensors
38
Managing devices
797
Management of remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add a device logon banner . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing devices access using TACACS+ . . . . . . . . . . . . . . . . . . . .
Management of SNMPv3 users . . . . . . . . . . . . . . . . . . . . . . . . .
Management of permitted NMS IP address . . . . . . . . . . . . . . . . . . . .
How to work with the Sensor MIBs . . . . . . . . . . . . . . . . . . . . . . .
View details of a selected device . . . . . . . . . . . . . . . . . . . . . . . . . . .
Edit device information . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to reboot devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reboot a device from the Manager . . . . . . . . . . . . . . . . . . . . . . .
Enable Sensor CLI audit log events to the Manager . . . . . . . . . . . . . . . . . . .
39
Monitoring Sensor Performance
811
How to configure and monitor device performance . . . . . . . . . . . . . . . . . . . .
View device performance settings summary . . . . . . . . . . . . . . . . . . . . . .
Enable device performance monitoring . . . . . . . . . . . . . . . . . . . . . . . .
Enable device performance monitoring for the admin domain . . . . . . . . . . . .
Enable device performance monitoring for specific devices . . . . . . . . . . . . .
Configuration of metrics collection . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure metrics collection for the admin domain . . . . . . . . . . . . . . . . .
Configure metrics collection for specific devices . . . . . . . . . . . . . . . . . .
Thresholds setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set the CPU utilization threshold for the admin domain . . . . . . . . . . . . . . .
Set the CPU utilization threshold for specific devices . . . . . . . . . . . . . . . .
Set the Sensor throughput threshold for devices within the admin domain . . . . . . .
Setting the Sensor throughput threshold for specific devices . . . . . . . . . . . . .
Set the L2 error drop threshold for devices within the admin domain . . . . . . . . .
Set the L2 error drop threshold for specific devices . . . . . . . . . . . . . . . .
Set the L3/L4 Error Drop threshold for devices within an admin domain . . . . . . . .
12
McAfee Network Security Platform 8.1
797
797
798
799
801
802
806
807
808
809
809
811
811
812
813
816
817
817
818
819
819
820
821
823
823
825
825
IPS Administration Guide
Contents
Set the L3/L4 error drop threshold for specific devices . . . . . . . . . . . . . . .
Set the port throughput utilization threshold for specific devices . . . . . . . . . . .
Customize metrics display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to monitor the device performance . . . . . . . . . . . . . . . . . . . . . . . .
How to monitor thresholds . . . . . . . . . . . . . . . . . . . . . . . . . .
How to monitor Sensor performance metrics . . . . . . . . . . . . . . . . . . .
View default Sensor performance monitors . . . . . . . . . . . . . . . . . . . .
Generation of device performance reports . . . . . . . . . . . . . . . . . . . . . . .
Device performance — Next Generation default reports . . . . . . . . . . . . . . .
Device performance — Next Generation user defined reports . . . . . . . . . . . .
Sensor performance — Traditional reports . . . . . . . . . . . . . . . . . . . .
Index
McAfee Network Security Platform 8.1
827
827
828
829
829
831
838
839
840
842
842
845
IPS Administration Guide
13
Contents
14
McAfee Network Security Platform 8.1
IPS Administration Guide
Preface
This guide provides the information you need to work with your McAfee product.
Contents
About this guide
Find product documentation
About this guide
This information describes the guide's target audience, the typographical conventions and icons used
in this guide, and how the guide is organized.
Audience
McAfee documentation is carefully researched and written for the target audience.
The information in this guide is intended primarily for:
•
Administrators — People who implement and enforce the company's security program.
•
Users — People who use the computer where the software is running and can access some or all of
its features.
Conventions
This guide uses these typographical conventions and icons.
Book title, term,
emphasis
Title of a book, chapter, or topic; a new term; emphasis.
Bold
Text that is strongly emphasized.
User input, code,
message
Commands and other text that the user types; a code sample; a displayed
message.
Interface text
Words from the product interface like options, menus, buttons, and dialog
boxes.
Hypertext blue
A link to a topic or to an external website.
Note: Additional information, like an alternate method of accessing an
option.
Tip: Suggestions and recommendations.
Important/Caution: Valuable advice to protect your computer system,
software installation, network, business, or data.
Warning: Critical advice to prevent bodily harm when using a hardware
product.
McAfee Network Security Platform 8.1
IPS Administration Guide
15
Preface
Find product documentation
Find product documentation
After a product is released, information about the product is entered into the McAfee online Knowledge
Center.
Task
16
1
Go to the McAfee ServicePortal at http://support.mcafee.com and click Knowledge Center.
2
Enter a product name, select a version, then click Search to display a list of documents.
McAfee Network Security Platform 8.1
IPS Administration Guide
Intrusion prevention and
Network Security Platform basics
Chapter 1
Chapter 2
Network security and McAfee Network Security Platform
Network Security Platform Basics
McAfee Network Security Platform 8.1
IPS Administration Guide
17
Intrusion prevention and Network Security Platform basics
18
McAfee Network Security Platform 8.1
IPS Administration Guide
1
Network security and McAfee Network
Security Platform
The network-security landscape is ever-changing. As technology gets sophisticated, so do the threats.
The Internet explosion exposed corporate networks to even teenagers sitting in their garages at home.
The hackers of those days were continuously trying to test the security of various systems and
networks. Some were simply seeking some sort of intellectual high, while others are fueled by more
treacherous motives, such as revenge or stealing for profit.
Hacking these days is very organized and focused. It involves a lot of planning, collaboration, and
persistence. Contemporary hackers are no more just the amateur individuals of yesteryears. On one
hand, you need to protect your network from hackers working for rich corporations and nation states.
On the other, you are up against ideology-driven hacktivism. In addition to these, the biggest
challenge for governments and defense establishments is cyber-terrorism.
These days your network is perpetually under one attack or the other. So, it is not enough if you just
ensure that all the doors and windows to your network are locked, and the alarm is turned on. In
addition to alerting on intrusions, malware, and policy violations, your security system needs to
provide you complete visibility into your network. Some of the things that you need to continuously
monitor are:
•
Who are the current users on your network.
•
The devices on your network.
•
The applications being used on your network.
•
The type and quantity of traffic traversing your network.
•
The source and destination of the traffic.
This section discusses some of the current threats to your network and how you can use Network
Security Platform to mitigate those threats.
Contents
Network security threats and trends
Fortifying your network using McAfee Network Security Platform
What are attacks and intrusions?
How Network Security Platform protects your network
McAfee Network Security Platform 8.1
IPS Administration Guide
19
1
Network security and McAfee Network Security Platform
Network security threats and trends
Network security threats and trends
As always, the challenges for security experts are on the rise. The technological advancements in the
availability of the Internet, mobile computing devices such as smart phones, social networks and other
Internet applications have all contributed to the current realm in network security.
As a security expert, you need to be aware of your challengers, the probable points of entry for
hackers, and the current techniques in hacking.
Who are you up against
With the challenges from individual, unorganized hackers still remaining true, the new generation of
hackers can be broadly classified into categories.
20
•
Hackers sponsored by corporations and nations (not necessarily rogue): The purpose here
is industrial or military espionage. As a security expert working for enterprises, the advantage that
you had over the previous generation hackers is the funds to buy the required facilities and
technology. This advantage is fast vanishing since your challengers are also equally funded if not
more.
•
Hacktivists: The purpose of these hackers is to retaliate against corporations or government
agencies for their decisions.
McAfee Network Security Platform 8.1
IPS Administration Guide
Network security and McAfee Network Security Platform
Network security threats and trends
•
Cyber terrorists: These hackers are ideology-driven but sponsored by rogue nation states.
•
Cyber criminals: These hackers work for international organized crime with the sole purpose of
targeting financially sensitive data.
1
Figure 1-1 Categories of hackers
Contributing factors to security threats
Technological advancements have contributed to the growth of businesses. However, this has also put
security professionals in an unenviable position. Review some of the main contributing factors to the
current security threat environment.
•
Internet-based business world: Across industries, organizations depend on the Internet to run
their business. Their network is open to their vendors, partners, customers, and even the public.
•
Mobile computing devices and BYOD: Handheld devices are now available with a very high
computing power and storage capacity. More and more organizations are encouraging the Bring
Your Own Device (BYOD) concept, wherein the employees bring their personal mobile devices to
their offices and use them for official purposes as well. While it is true that BYOD can save money
McAfee Network Security Platform 8.1
IPS Administration Guide
21
1
Network security and McAfee Network Security Platform
Network security threats and trends
and space for the organization, the flipside is that it is a huge security threat. To mitigate this
threat, your security system must be able to:
•
•
Detect the device and its type as soon as it comes on to your network.
•
Quickly assess the device's posture, detect the user logged on, and the Wireless Access Point to
which it is connected and grant the appropriate access.
•
Detect and report any undesired activity involving the device.
Internet applications and their usage: Internet-based applications such as social networking
sites and multimedia-based applications come with their own set of vulnerabilities. More the
features, more are the chances for vulnerabilities. It is not just the recreational applications, but
business and productivity applications that users find to be more powerful and capable compared
to the equivalents approved by your organization. In some cases, organizations do allow some of
the open Internet applications to be used for business purposes. This means that your security
system must be capable of identifying each and every application on your network for you to
control the undesired ones.
In addition to the vulnerabilities of the applications, the network bandwidth consumed by these
applications is also a concern. For example, you cannot allow a video-based recreational application
to cause network bandwidth deficiency during business hours.
•
Storage devices: Over the years, storage devices have been increasing in capacity but decreasing
in size and cost. Your security system must be capable of validating the data coming from and
going to such devices.
•
Easy availability of hacking tools: You do not need to be technical savvy to be a hacker. One
can buy the required hacking tools over the Internet.
What are you up against?
Every technological advancement provides new options to hackers. Review some of the popular trends
that are used to attack networks.
22
•
Exploits: A hacker attempts 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.
•
Advanced persistent threats (APTs): APTs are unrelenting attacks against specific networks
over a long period of time. APTs are purpose oriented. They target specific networks for specific
goals. The attackers probe the target network for the most feasible entry point and then launch the
attacks using the most appropriate technique. It could be a complex or a simple technique but one
that can help them achieve their goals. The attackers take care to remain undetected and persist
with different methods until they succeed. The usual purpose is to gain financially or intellectually.
McAfee Network Security Platform 8.1
IPS Administration Guide
1
Network security and McAfee Network Security Platform
Network security threats and trends
It is very difficult to trace the source because APTs are mostly sponsored by nation states.
Therefore, they are backed up by people, technology, and almost unlimited funds.
•
Advanced malware: Earlier users received malware as attachments in their emails. With the
upsurge in Internet applications, users only need to click on a link to download files. Today,
there are many other options to post such files - blogs, social networking sites, Websites, chat
messages, Webmails, message boards, and so on. Your security system must not only be able
to detect known malware but zero-days ones as well.
•
Bots: These are malware running on compromised systems. They are part of a larger, centrally
managed network of such compromised systems. This network of compromised systems
reporting to one command and control system is referred to as a botnet.
•
DoS and DDoS: Denial of Service (DoS) attack is a malicious attempt to render a service,
system, or network unusable by its legitimate users. The previous generation DoS attacks do
not require the attacker to gain access or entry into the targeted server. The primary goal of
such DoS attacks is to deny legitimate users access to the service provided by that server.
Distributed Denial of Service (DDoS) involves many compromised hosts across the Internet, to
launch a DoS attack. Attackers typically use various tools to launch DoS and DDoS attacks.
DoS attacks have now evolved to exploit vulnerabilities in the web applications themselves. The
aim is to turn off the service, thereby denying access to legitimate users. This technique
produces the same result as the traditional DoS but costs less in terms of time and money.
•
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.
•
SQL injections: Because of their location and their functionality, Web servers are usually the
favorites for hackers. Mere signature-based detection cannot adequately protect your servers. You
need an IPS that can quickly and intelligently detect SQL injections.
•
Bandwidth-consuming applications: As a security expert, you must be concerned not just
about attacks but also about multimedia-rich applications bringing your network to a halt by
consuming the majority of the available bandwidth. Your security system must be capable of
identifying and regulating application traffic.
•
Virtual environments: Organizations are increasingly moving towards virtual environments. So,
your security system must be capable of inspecting traffic between virtual machines residing on the
same host.
•
Applications using non-standard ports: Current threats involve exploiting the use of
non-standard ports to evade the IPS boxes. Your security system must be intelligent enough to
address this issue.
McAfee Network Security Platform 8.1
IPS Administration Guide
23
1
Network security and McAfee Network Security Platform
Fortifying your network using McAfee Network Security Platform
•
Browser-based attacks: Browsers have become feature-rich and very user friendly with the
support for new features, including HTML 5. However, this also offers new opportunities for
hackers.
•
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 your network as defined by your 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 does not 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.
Figure 1-2 The network security threat landscape
Fortifying your network using McAfee Network Security
Platform
Contemporary hackers have more resources at their disposal, especially when backed up by rival
corporations and nation states. Your security system must be very dynamic, intelligent, and proactive
to help you meet evolving techniques and successfully defend your network every time. As a reactive
strategy, it must be capable of blocking attacks and warn you of any strange activity in your network.
For the proactive part, your security system must be capable of notifying the vulnerabilities in your
network and also provide you the visibility of even the normal traffic on your network. A proactive
security system enables you to be a step ahead of your challengers.
McAfee Network Security Platform is a network-based IPS that combines purpose-built network
security devices and management software for the accurate detection and prevention of known
attacks using signature detection and zero-day attacks using anomaly detection. It also provides you
next-generation IPS features such as internal-firewall and QoS.
24
McAfee Network Security Platform 8.1
IPS Administration Guide
Network security and McAfee Network Security Platform
What are attacks and intrusions?
1
The add-on McAfee® Network Threat Behavior Analysis appliance monitors and presents you a
real-time view of your network traffic. Network Security Platform also collaborates with other McAfee
products on your network to provide you complete network protection.
What are attacks and intrusions?
Network Security Platform considers any unauthorized action taken with the intent of hindering,
damaging, incapacitating, or breaching the security of your network as an attack. An attack typically
prepares for or carries out threats to your critical assets. Attacks can be active, wherein the goal is to
directly exploit some vulnerability in a 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. When you install Network Security Platform
in the prevention (IPS) mode, it detects and blocks attacks. In the detection (IDS) mode, it reports
the attacks. However, based on the type of attack, the attack traffic might have reached the intended
target.
How Network Security Platform protects your network
Network Security Platform offers multi-gigabit performance, flexible deployment, robust scalability,
and easy-to-use intrusion detection and prevention. Network Security Platform goes beyond the
simple string matching. 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 Network Security
Platform'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. Network Security Platform then passes the parsed
packet through its other engines such as the DoS, Signature and Anomaly detection engines, Malware
engine, and internal Firewall engine. This enables Network Security Platform 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 designed to provide the required wire-speed
performance.
If the detection engines detect something abnormal, 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 Manager. This response can include
blocking the corresponding traffic entirely and even quarantining the attacking host.
In addition to dropping malicious traffic, Network Security Platform 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/IPS and other security devices.
McAfee Network Security Platform 8.1
IPS Administration Guide
25
1
Network security and McAfee Network Security Platform
How Network Security Platform protects your network
The accuracy level of Network Security Platform is exceptionally high due to the following factors:
•
Full protocol analysis and state tracking
•
Multi-trigger, multi-field pattern matching
•
Network Security Platform's ability to see all of the traffic in a variety of deployment modes,
including active/active, active/passive, and asymmetrically routed traffic environments.
Protection against APTs: Network Security Platform performs deeper inspection of traffic to detect
malicious file downloads and bots. It uses various malware scanning options for advanced malware
protection. This includes an embedded PDF emulator that detects zero day java script threats in PDF
downloads. It also runs the gateway anti malware engine on the NTBA appliance. In addition, Network
Security Platform extracts potentially malicious files that can be submitted to McAfee cloud for
analysis. The submitted files are then executed in a virtual environment.
For bot-detection, Network Security Platform correlates multiple attacks across different flows by
observing a host over a given period of time. It also forwards the attack information to the NTBA
appliance for similar correlation.
Network Security Platform detects DoS and DDoS through threshold-based and self- learnt
profile‑based detection techniques. In addition, it provides a connection-limiting feature that limits the
number of connections a host can establish.
Protection for web applications: Network Security Platform provides various features to protect
your web application serves. For example, it employs a heuristic engine to detect SQL injections.
Network Security Platform can inspect HTTP responses to ensure your servers are not compromised. If
you can import the server's private key, Network Security Platform Sensor can decrypt and analyze
SSL traffic. Post-inspection, it encrypts the traffic back.
Application Identification: Network Security Platform can identify the applications traversing your
network and act on them as you configured. So, you can allow or block specific applications or
application features on your network. For example, you can block the connections to Facebook from
your network while allowing all other HTTP traffic .
Identifying users and user groups: Network Security Platform integrates with McAfee Logon
Collector to identify the Windows AD users on your network and also the user groups to which they
belong. This means that you can now control based on users rather than their IP addresses, which is
not always reliable. For example, a dynamic IP address might differ based whether the user connects
from office or outside office.
Next-generation IPS features: Network Security Platform provides next-generation IPS features
such as internal Firewall and QoS.
You can create different Firewall rules for different segments of your network. You can base these
rules on the traditional 5-tupple with support for IPv6. In addition, you can base them on the
applications, application features, Windows AD user data, geographical location, and time. This
enables you to control the privileges of your network users regardless of whether they log on from
home, airport, or office.
The Senor evaluates the traffic against the Firewall rules before checking it for attacks. So, you can
use this feature to filter the traffic that must be inspected for attacks.
You can create QoS rules based on similar criteria as for Firewall. These rules ensure that the required
network bandwidth is always available for your business applications and not consumed by other
applications such as social-network or video-streaming applications.
26
McAfee Network Security Platform 8.1
IPS Administration Guide
Network security and McAfee Network Security Platform
How Network Security Platform protects your network
1
Identifying the host type: Network Security Platform profiles devices to address risks due to BYOD.
It integrates with McAfee ePO and NTBA to identify the device type and the operating system for each
host on your network. You are now aware of the types of devices on your network. If a specific host is
targeted for an attack, you can also assess if that attack is relevant based on the device type and OS.
Protection for virtual machines: Virtual instances of Sensors enable you to monitor peer-to-peer
traffic between virtual machines even within the same virtual host. Virtual Network Security Platform
Sensors are called as Virtual IPS Sensors or Virtual Sensors. You can deploy a Virtual IPS Sensor as a
virtual appliance in a virtualization platform such as VMware ESXi server. Then, you can configure the
Virtual IPS Sensor to protect the virtual network within the virtualization platform or even outside.
Based on the network design and security requirements, you can configure a Virtual IPS Sensor to be
inline between virtual machines or configure it in the IDS mode. It is also possible to use a Virtual IPS
Sensor to inspect traffic between physical hosts.
In addition to the Virtual IPS Sensors, you can integrate a Network Security Manager with third-party
applications to protect virtual machines. The supported third-parties are VMware and Reflex. When a
physical or a Virtual IPS Sensor detects attacks from virtual machines, the Manager collaborates with
the integrated third-party application to quarantine the attacking virtual machine. This option makes
the Network Security Platform deployment more flexible and also enables you to make optimum use of
your network products to secure your network.
Cloud-based IP and file reputation: To protect your network from known and near zero-day
malware, Network Security Platform integrates with McAfee Global Threat Intelligence. It can check if
an email, URL, or a file is known malware. It can also check the reputation of IP address and port
combination when an external host attempts to communicate with a host on your network.
Quarantine host and enforce remediation: If an internal host generates attack traffic, it could be
that it is compromised. You can use Network Security Platform to manually or automatically
quarantine such hosts until they are remediated.
McAfee Network Security Platform 8.1
IPS Administration Guide
27
1
Network security and McAfee Network Security Platform
How Network Security Platform protects your network
Analyzing your network traffic: The IPS Sensor integrates with the NTBA appliance to proactively
provide visibility into any anomalous behavior on your network. They passively monitor your network
to help identify threats from APTs and to even troubleshoot network issues. NTBA collects a vast
amount of data, which is converted to meaningful and relevant information, and presented to you in
an easy-to-understand graphical format.
Integrating with other McAfee products: One of the biggest advantage that Network Security
Platform provides is the ability to integrate with other McAfee products.
The previous paragraphs explained why Network Security Platform integrates with McAfee ePO,
McAfee Logon Collector, and McAfee GTI. In addition, it integrates with the following McAfee products
as well:
28
•
Integration with McAfee ePO : As mentioned earlier, this integration enables Network Security
Platform in identifying the devices on your network. You can also query for the complete details of
any ePO-managed host on your network.
•
Integration with McAfee GTI : As explained previously, this integration facilitates Network Security
Platform to check the reputation of a file, URL, email, IP, and network.
•
Integration with McAfee Host Intrusion Prevention: This integration enables you to view the
events logged by the Host Intrusion Prevention on the host itself. If a host attacks another on the
same VLAN, this traffic might not reach Network Security Platform. However, Host Intrusion
Prevention on the target host can block this attack and you are notified of this even through
Network Security Platform as well.
McAfee Network Security Platform 8.1
IPS Administration Guide
Network security and McAfee Network Security Platform
How Network Security Platform protects your network
1
•
Integration with McAfee Vulnerability Manager : When a host is targeted, Network Security
Platform alerts you. From the management console of Network Security Platform, you can verify if
the host is really vulnerable for that attack and not worry about it if the attack is not relevant.
•
Integration with McAfee Logon Collector : This integration enables Network Security Platform to
identify the Windows AD users and their hosts to apply the security policies accordingly.
Figure 1-3 Integration with other McAfee products
Flexible deployment options: Network Security Platform provides devices of various throughput
capacities to meet today's higher speed network segments. They are designed to provide
comprehensive protection without compromising on performance. The throughput of these devices
range from 100 Mbps allows you to protect ranging from 100 Mbps up to 40 Gbps. If you use Network
Security Platform XC-240 Load Balancer and Network Security Platform M-8000XC Sensor as an XC
Cluster, then you can scale up to even 80 Gbps. Network Security Platform 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 Sensor models contain built-in 10/100 Mbps 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 Sensors empowers
comprehensive network-wide IPS deployment with significantly fewer Sensors.
The latest Network Security Platform devices come with hardware acceleration for supporting
encryption, decryption, and decompression. They use Intel's high-performance processors to deliver
higher throughput.
McAfee Network Security Platform 8.1
IPS Administration Guide
29
1
Network security and McAfee Network Security Platform
How Network Security Platform protects your network
VIPS - applying policies at the interface and sub-interface levels: The VIPS feature enables you
to configure multiple policies for multiple unique environments and traffic directions all monitored with
a single 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 M-1450 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. In this
case, each monitoring port of the Sensor is an interface. The other option is to segment each
monitoring port by multiple VLAN tags or CIDR addresses, each customized with its own security
policy. In this case, each monitoring port is segmented into virtual sub-interfaces.
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.
Network Security Platform also supports Manager Disaster Recovery (MDR) for its management
console. If, for any reason, the primary McAfee® Network Security 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 Network Security
Platform 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.
Also, Virtual IPS Sensors are remarkably quick and easy to deploy. Therefore, they greatly enhance
scaling up your next-generation IPS deployment without any compromise on security features.
30
McAfee Network Security Platform 8.1
IPS Administration Guide
2
Network Security Platform Basics
This section provides an overview of McAfee® Network Security Platform and its components.
Network Security Platform overview
McAfee Network Security Platform [formerly McAfee IntruShield®] is a combination of network
appliances and software built for the accurate detection and prevention of intrusions, denial of service
(DoS) attacks, distributed denial of service (DDoS) attacks, malware download, and network misuse.
Network Security Platform provides comprehensive network intrusion detection and can block, or
prevent, attacks in real time, making it truly an intrusion prevention system (IPS).
Network Security Platform components
The following are the major Network Security Platform components for IDS and IPS:
•
McAfee Network Security Sensor (Sensor)
•
McAfee Network Security Manager (Manager), with its Web-based graphical user interface
•
McAfee Update Server
Sensors
Sensors are high-performance, scalable, and flexible content processing appliances built for the
accurate detection and prevention of intrusions, misuse, malware, denial of service (DoS) attacks, and
distributed denial of service (DDoS) attacks. Sensors can be physical or virtual appliances. 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, a 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 through
the Manager server.
•
In this chapter, the term Sensor applies to both physical as well as Virtual IPS Sensors unless
otherwise specified.
•
In this guide, the term Sensor resources refers to the monitoring ports, interfaces, and
subinterfaces of a physical or a Virtual IPS Sensor.
Sensor functionality
The primary function of a device is to analyze traffic on the selected network segments and to respond
when an attack is detected. The device examines the header and data portion of every network
packet, looking for patterns and behavior in the network traffic that indicate malicious activity. The
McAfee Network Security Platform 8.1
IPS Administration Guide
31
2
Network Security Platform Basics
Network Security Platform overview
device examines packets and matches the packets against the applied policies. These policies
determine what attacks to watch for, and how to respond with countermeasures if an attack is
detected.
If an attack is detected, a physical or a Virtual IPS Sensor responds according to its configured policy.
A Sensor can perform many types of attack responses, including generating alerts and packet logs,
resetting TCP connections, “scrubbing” malicious packets, and even blocking attack packets entirely
before they reach the intended target.
In addition to its primary function of preventing exploit, recon, and DoS attacks, a Sensor can also do
the following:
•
Detect malware— A Sensor uses various methods to inspect files being downloaded for
embedded malware. If a malware is detected, the Sensor blocks the download and takes further
response actions.
•
Enforce Firewall access rules— You can define Firewall access rules (similar to ACLs) in the
Manager. Then you can configure a Sensor to enforce these rules on your network.
•
Provide and facilitate Quality of Service (QoS)— You can configure a physical Sensor to
provide QoS using the rate limiting technique. Additionally, a physical Sensor can facilitate
Differentiated Services and IEEE 802.1p by differentiating traffic and tagging them accordingly.
•
Provide connection limiting services— Based on how you configure, a Sensor can limit the
number of connections a host can establish. One of the advantages of connection limiting is that it
can minimize connection-based DoS attacks.
•
Export NetFlow data— If McAfee Network Threat Behavior Analysis (NTBA) is deployed, you can
configure a Sensor to export NetFlow data to the NTBA Appliance.
Sensor platforms
Network Security Platform offers several types of Sensor platforms providing different bandwidth and
deployment strategies.
•
I-series: I-4010, I-4000, I-3000, I-2700, I-1400, and I-1200
•
M-series: M-8000, M-6050, M-4050, M-3050, M-2850, M-2950, M-2750, M-1450, and M-1250
•
NS-series: NS9100, NS9200 and NS9300
•
Virtual IPS Sensors: IPS-VM100 and IPS-VM600
I-series Sensors
32
I-4010
I-4000
I-3000
I-2700 I-1400
I-1200
10/100 Base-T
Monitoring Port
Nil
Nil
Nil
6
4
2
10/100/1000
Gigabit Ethernet
Monitoring Port
12
4
12
2
Nil
Nil
RJ-45 Response
Port
2
2
3
1
1
Ports Used for
Failover
6A and 6B
2A and 2B 6A and 6B
4A
Response
port
Response
port
Internal Taps
Nil
Nil
Nil
Yes
Yes
Yes
Fail-open Control
Ports
6
2
6
Nil
Nil
Nil
10/100/1000
only with
Copper SFP
McAfee Network Security Platform 8.1
10/100/1000
only with
Copper SFP
2
IPS Administration Guide
2
Network Security Platform Basics
Network Security Platform overview
I-4010
I-4000
I-3000
I-2700 I-1400
I-1200
10/100
Management port
1
1
1
1
1
1
Console Port
1
1
1
1
1
1
Auxiliary Port
1
1
1
1
1
1
Redundant power
supply
Yes
Yes
Yes
Yes
Nil
Nil
Fail-closed
dongles
Nil
Nil
Nil
6
4
2
M-6050
M-4050
M-2850
M-3050
M-2950
Nil
4 built-in
10/100/1000
RJ-45 ports
Nil
12 One Gigabit
SFP ports
20 SFP
ports
M-series Sensor
M-8000
M-2750
M-1450
M-1250
10/100 Base-T
Monitoring Port
Nil
Interface
Module
8 SFP
16 One
Gigabit SFP ports
ports
8 XFP
ports
12 Ten
Gigabit XFP
ports
4 XFP
ports
RJ-45 Response
Port
1
1
1
1
1
1
Ports Used for
failover
3A and 3B
4A
2A
6A
10A
4A
Note that
10B is
unused.
Note that 4B is
unused.
Internal Taps
Nil
Nil
Nil
Nil
Nil
Yes
Fail-open
Control Ports
14
8
6
6
10
Nil
Interconnect
ports
4 Ten
Gigabit
XFPs
Nil
Nil
Nil
Nil
Nil
Nil
8 built-in
10/100/1000
RJ-45 ports
8 SFP
ports
Note that
4B remains
unused.
2 RJ-45
ports
10/100/1000
Management
port
1
1
1
1
1
1
Console Port
2
1
1
1
1
1
Auxiliary Port
2
1
1
1
1
1
Redundant
power supply
Yes
Yes
Yes
Yes
Yes
Nil
Fail-closed
dongles
Nil
Nil
Nil
Nil
Nil
Nil
McAfee Network Security Platform 8.1
IPS Administration Guide
33
2
Network Security Platform Basics
Network Security Platform overview
NS-series Sensor
Ports
NS9100/NS9200
NS9300
Fixed Gigabit Ethernet—
Copper Ports
8
16
Fixed 40-Gigabit Ethernet
2
4 (used as interconnect ports
between NS9300P and NS9300S )
Network I/O Slots
2
4
Network I/O Modules (four
options)
8 port (SFP+/SFP) 10 GigE/1
GigE
8 port (SFP+/SFP) 10 GigE/1 GigE
(internal fail-open)
6 port RJ-45 10/100/100 Mbps
2 port (QSFP+) 40 GigE
6 port RJ-45 10/100/100 Mbps
2 port (QSFP+) 40 GigE
4 port (QSFP+) 40 GigE
4 port (QSFP+) 40 GigE
10 Gigabit Ethernet
Modular up to 16
Modular up to 32
40-Gigabit Ethernet
Modular up to 8
Modular up to 16
10/100/100 Mbps
Modular up to 12
Modular up to 24
Dedicated Response Ports
(RJ45)
1 (10G/1G/100M)
1 (10G/1G/100M) on NS9300S
Dedicated Management Ports 1 (10G/1G/100M)
(RJ45)
1 (10G/1G/100M) on NS9300P
Dedicated Auxillary Port
(RJ45)
1 (10G/1G/100M)
2 (10G/1G/100M)
USB ports
2
4
Virtual IPS Sensor models
The table describes the available Virtual IPS Sensor models.
Model
Maximum
Sensor
throughput
Number of
monitoring
ports
Management
port
Response
port
Logical
CPU
Cores
Memory
Storage
IPS-VM100 100 Mbps
4
1
1
3
6 GB
minimum
required.
50 GB
IPS-VM600 600 Mbps
6
1
1
4
6 GB
minimum
required.
100 GB
The kind of traffic being inspected and the features that you enable are some of the primary factors that
affect the throughput of a Sensor. For these details and other capacity values for Virtual Sensors, see
the Virtual IPS Sensor capacity by model number section in the Network Security Platform 8.1 Best
Practices Guide.
Manager components
The Manager is a term that represents the hardware and software resources that are used to configure
and manage the Network Security Platform. The Manager consists of the following components:
34
•
Manager server platform
•
The Manager software
McAfee Network Security Platform 8.1
IPS Administration Guide
2
Network Security Platform Basics
Network Security Platform overview
•
A back-end MySQL database that is installed along with the Manager
•
A connection to McAfee Update Server
Manager server platform
The Manager server platform hosts the Manager software and the Manager database. It is a server
running on an operating system as specified in the Network Security Platform Installation Guide. You
can remotely access the Manager user interface from a client machine using a browser. Refer to the
Installation Guide to know the supported browsers and the supported operating systems for the
clients.
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 server; however, this
means you can only receive information from one Sensor (typically, your server has only one 10/100
network port). During the Sensor configuration, you will establish communication between your
Sensors and your Manager server.
Manager software
The Manager software has a Web-based user interface for configuring and managing Network Security
Platform. Users connect to the Manager server from a supported client using a supported browser, the
details of which are in the Installation Guide. The Manager functions are configured and managed
through a GUI application, which includes complementary interfaces for alerts, system status, system
configuration, report generation, and fault management. All interfaces are logically parts of the
Manager program.
The Manager user interface has five main tabs:
•
Dashboard — The Dashboard is the first page displayed after the user logs on to the system. Options
available within the page are determined by the current user's assigned roles. The Dashboard
enables you to view all the critical information regarding Network Security Platform deployment in
the same page. The Dashboard is very user configurable. You can configure the information that
you want to view, the timeframe for which you want to view the information, the frequency with
which the Dashboard must auto-refresh, and so on. All this information can be customized to view
for a particular admin domain. You can select the admin domain from the Domain drop-down list to
display data for the selected admin domain.
Some of the information displayed on the dashboard includes:
•
Messages from McAfee
•
Information regarding the frequently seen malicious activities on your network. This includes
things such as the most downloaded malware, most active botnets, the most targeted hosts,
the most detected attack and so on.
•
System health of Network Security Platform components. That is, whether all the components
are functioning properly., the number of unacknowledged alerts in the system, and the
configuration options available to the current user.
•
Manager-related details such as the version, signature set version, users logged on to the
Manager, and so on.
•
Information like whether the devices are up-to-date.
McAfee Network Security Platform 8.1
IPS Administration Guide
35
2
Network Security Platform Basics
Network Security Platform overview
•
Analysis — This tab presents the options using which you can view the granular details of all the
malicious activities on your network. The intention here is to provide you all the critical information
needed for further analysis fro the selected admin doamin.
One of the key options under the Analysis tab is the option to launch the Threat Analyzer, which
displays the alerts triggered by the Sensors. The Threat Analyzer page displays the hosts detected on
your network as well as the detected security events that violate your configured security policies.
The Threat Analyzer 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.
•
Policy — All the major features in Network Security Platform are policy based. For example, to block
exploit and recon attacks, you use the IPS and the recon policies; for Firewall, you use the Firewall
policies; for QoS, you use the QoS policies and so on. The Policy tab provides the options to
manage all these policies and other related functionality.
•
Devices — You can use the same instance of the Manager to manage both the physical and virtual
devices. The Devices tab provides all system configuration options, and facilitates adding and
configuration of your devices - Sensors and NTBA Appliances, failover pairs of Sensors. This tab
also provides configuration options on a per device basis as well. Access to various activities is
based on the current user's role(s) and privileges, administrative domains, users, roles, attack
policies and responses, user-created signatures, and system reports.
•
Manage — This tab provides the configuration options related to the Manager software. This includes
managing administrative domains, users, roles, download IPS signature sets and other software
such as Sensor software, integrating the Manager with other McAfee products, maintenance
activities such as database backups, and so on. the options to configure the options in the
Manager.
Other key features of Manager include:
36
•
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 Threat Analyzer.
•
Integration with other McAfee products— You can integrate Network Security Platform with
other McAfee products to provide you with a comprehensive network security solution.
•
McAfee ePolicy Orchestrator — McAfee ePolicy Orchestrator (ePO) is a scalable platform for
centralized policy management and enforcement of your system security products such as,
anti-virus, desktop firewall, and anti-spyware applications. You can integrate McAfee Network
Security Platform with ePO 4.0. The integration enables you to query the ePO server from the
Manager for viewing details of a network host.
•
McAfee Host Intrusion Prevention— McAfee Host Intrusion Prevention (HIP) is a host-based
intrusion prevention system that prevents external and internal attacks on the hosts in the
network, thus protecting services and applications running on them. Network Security Platform
integrates with McAfee Host Intrusion Prevention version 7.0.
•
McAfee Vulnerability Manager — Vulnerability assessment is an automated process of
pro-actively identifying vulnerabilities of computing systems in a network to determine security
threats in the network. Network Security Platform integrates with McAfee Vulnerability Manager
to enable import of the Vulnerability Manager scan data into the Manager, to provide automated
updating of IPS-event data relevancy. You can also initiate a Vulnerability Manager on-demand
scan of a single or group of IP addresses directly from the Threat Analyzer console. This
provides a simple way for security administrators to access near real-time updates of host
vulnerability details, and improved focus on critical events.
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform Basics
Network Security Platform overview
2
•
McAfee File Reputation — Network Security Platform integrates with McAfee File Reputation
technology, which is an Internet-based service that provides active malware detection in an
Internet cloud. Network Security Sensors use McAfee File Reputation to provide real-time
malware detection and protection for users during file downloads from the Internet. Network
Security Platform also provides users the option to upload Custom Fingerprints that can be used
for malware detection.
•
McAfee Global Threat Intelligence — McAfee Global Threat Intelligence (GTI) is a global
threat correlation engine and intelligence base of global messaging and communication
behavior; including reputation, volume, trends, email, web traffic and malware. By having
McAfee Global Threat Intelligence integration, you can report, filter, and sort hosts involved in
attacks based on their network reputation and the country of the attack origin.
For more information on all the above mentioned integration options, see McAfee Global Threat
Intelligence Integration Guide.
•
Integration with third-party products — Network Security Platform 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 want 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
Packet log viewing— View logged packets/flows using third-party software, such as Ethereal.
Manager database
The Manager server operates with an RDBMS (relational database management system) for storing
persistent configuration information and event data. The compatible database is MySQL. Refer to the
Installation Guide for the current version of MySQL.
The Manager server includes a MySQL database that is installed (embedded) on the target Windows
server during Manager software installation.
Your MySQL database can be tuned on-demand or by a set schedule through the Manager user
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 from the MySQL Web site http://dev.mysql.com/downloads/gui-tools.
McAfee Update Server
For your Network Security Platform 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 Network Security Platform 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
37
2
Network Security Platform Basics
Network Security Platform overview
®
New signatures and patches are made available to customers via McAfee Network Security Update
Server (Update Server). The Update Server is a McAfee owned and operated file server that houses
updated signature and software files for 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.
Obtaining updates from the Update Server
You have the following options for obtaining updates from the Update Server:
1
Connecting directly from your Manager server (via Manager interface action).
2
Connecting through a proxy server (through Manager interface action). You will then authenticate
as in option 1.
3
Connecting from a Manager client, 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.
4
Connecting from a Manager client, 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. For more information, see McAfee Network Security Platform
Installation Guide.
Configuring software and attack signature updates
You can configure interaction with the Update Server using the Manager. You can pull updates from the
Update Server on demand or you can schedule update downloads. With scheduled downloads, the
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.
38
•
Automatic update to Manager, manual update from Manager to Sensors— This option
enables Manager server to receive updates automatically, but allows the administrator to
selectively apply the updates to the Sensors.
•
Manual update to Manager, automatic update from 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 administrator to determine which signature
update to apply per update, and when to push the update out to the Sensors. You may want 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 Manager, and from the Manager to the Sensors without any intervention by the
security administrator. Note that fully automatic updating still happens at the 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
Deploying the Sensors for Next
Generation IPS and IDS
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
3
4
5
6
7
8
9
Network Security Platform deployment - an overview
Configuring the monitoring and response ports of a Sensor
Deployment of Sensors in inline mode
How to configure Sensors for high availability
Virtual IPS Sensor deployment
How to understand virtualization
Troubleshooting
McAfee Network Security Platform 8.1
IPS Administration Guide
39
Deploying the Sensors for Next Generation IPS and IDS
40
McAfee Network Security Platform 8.1
IPS Administration Guide
3
Network Security Platform deployment an overview
The process of setting up and running Network Security Platform falls into these basic stages:
1
Deciding where to deploy McAfee® Network Security Sensor (Sensor) and in what operating mode
2
Setting up your Sensors for the desired deployment mode(s)
3
Installing the Manager software and establishing Sensor-to-McAfee® Network Security Manager
(Manager) communication
4
Configuring your deployment using the Manager
5
Viewing and working with data generated by Network Security Platform
6
Tuning your deployment
7
Updating your signatures and software
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.
For information on how to deploy Virtual IPS Sensors, proceed to Virtual IPS Sensor deployment .
Contents
Decide where to deploy Sensors and in what operating mode
Sensor deployment modes
How to plan your IPS deployment
Establish Sensor-to-Manager communication
Configure your deployment using the Manager
View and work with data generated by Network Security Platform
Tune your deployment
Update your signatures and software
McAfee Network Security Platform 8.1
IPS Administration Guide
41
3
Network Security Platform deployment - an overview
Decide where to deploy Sensors and in what operating mode
Decide where to deploy Sensors and in what operating mode
This is one of the very first decisions that you need to make. 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 based on your company's security requirements.
•
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 the
Pre-deployment Considerations section of this document. 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 Network Security Platform deployment. After you name a Sensor, you cannot rename it
without de-installing the Sensor-to-Manager communication. After renaming the Sensor, you must
reinstall this communication.
Review of pre-deployment considerations
Deployment of Network Security Platform requires specific knowledge of your network's security
needs. Read this section to determine which the Sensor model will best suit your environment, and
what in what operating mode you'll need to employ each Sensor port.
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. You must also factor in the redundancy requirements for your network.
Knowing how your business will grow can help determine the amount of equipment you will require
and the proper strategy for network placement. Network Security Platform is built with growth in
mind. The Network Security Platform can manage multiple Sensors, and Sensors can scale in
performance from 100 Mbps to multi gigabits per second (up to 80 Gbps) for monitoring network
segments.
Access points 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 the key to any successful IDS installation.
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.
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.
42
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Decide where to deploy Sensors and in what operating mode
3
Determination of complexity of your network topology
Asymmetrically routed networks are complex environments that require careful planning and
execution.
The following figure shows a network protected by the Sensor in tap operating mode. Since both links
are monitored by the same Sensor, the state machine remains in sync. The 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.
Figure 3-1 Network topology
Traffic flow across 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. Network Security Platform offers multiple
Sensors providing different bandwidths:
McAfee Network Security Platform 8.1
IPS Administration Guide
43
3
Network Security Platform deployment - an overview
Decide where to deploy Sensors and in what operating mode
Sensor bandwidth
I-series Sensor
Aggregate performance
I-1200
100 Mbps
I-1400
200 Mbps
I-2700
600 Mbps
I-3000
1 Gbps
I-4000
2 Gbps
I-4010
2 Gbps
M-series Sensor
Aggregate performance
M-8000
10 Gbps
M-6050
5 Gbps
M-4050
3 Gbps
M-3050
1.5 Gbps
M-2750
600 Mbps
M-1450
200 Mbps
M-1250
100 Mbps
NS-series Sensor
Aggregate performance
NS9100
10 Gbps
NS9200
20 Gbps
NS9300
40 Gbps
Find where your security operations are 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 McAfee® Network Security 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.
Deployment of 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 (that is, 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.
44
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Decide where to deploy Sensors and in what operating mode
3
An illustration of the advantage of Sensors' multiple segment monitoring is to consider the question of
installing Sensors with respect to firewalls. It is very common to deploy 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, you would have to deploy multiple
Sensors to get the required coverage (as shown on the left side of the following figure). 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
45
3
Network Security Platform deployment - an overview
Decide where to deploy Sensors and in what operating mode
Consider the same scenario using the I-2700 Sensor (as shown on the right side of the following
figure). 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.
Figure 3-2 Scenario 1
Figure 3-3 Scenario 2
46
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
Sensor deployment modes
This section presents suggestions for implementing McAfee® Network Security Platform in a variety of
network environments.
Flexible deployment options
McAfee Network Security Platform offers unprecedented flexibility in Sensor deployment. 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 Sensor can monitor many network segments in any
combination of operating modes—that is, the monitoring or deployment mode for the Sensor—SPAN,
Tap, or In-line mode. For example, I-3000 or I-4010 can handle up to 12 network segments.
Additionally, Network Security Platform'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. What
more, you can enforce policies that are tailor-made for each of those network segments.
Supported deployment modes
Every port on the Sensor supports the following deployment modes:
•
SPAN or Hub
•
Tap
•
In-line, fail-closed
•
In-line, fail-open
Additionally, Network Security Platform provides features vital to today's complex networks: interface
groups (also called port clustering), and High-Availability.
McAfee Network Security Platform 8.1
IPS Administration Guide
47
3
Network Security Platform deployment - an overview
Sensor deployment modes
In the following example, a single Network Security Platform I-2700 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 3-4 Deployment example
In this example, the ports on this I-2700 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
Sensors are equipped with multiple Monitoring and Response ports. By default, the Sensor ports are
internally wire matched (that is, 1A and 1B) to monitor traffic in full-duplex pairs, that is, two
detection ports work together to monitor traffic flowing in both directions.
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).
48
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
I-series Sensor model Supported number of full-duplex Supported number of half-duplex
links
links
I-1200
1
2
I-1400
2
4
I-2700
4
8
I-3000
6
12
I-4000
2
4
I-4010
6
12
M-series Sensor model Supported number of full-duplex Supported number of half-duplex
links
links
M-8000
28
16
M-6050
16
8
M-4050
12
8
M-3050
12
8
M-2750
20
20
M-1450
8
8
M-1250
8
8
•
In-line mode and tap mode 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.
SPAN port and hub monitoring
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 Network Security Platform 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.
SPAN port and hub monitoring
When monitoring a SPAN or hub port, Sensors with internal taps are disabled.
McAfee recommends connecting cables to your Fast Ethernet ports with fail-closed dongles if deploying
in SPAN or Hub mode.
McAfee Network Security Platform 8.1
IPS Administration Guide
49
3
Network Security Platform deployment - an overview
Sensor deployment modes
In the following figure showing 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 3-5 SPAN port monitoring
Deployment of 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 S processors for analysis.
Full-duplex taps split a link into separate transmit and receive channels. 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 Tap mode) can work in one of two ways for the 10/100 Monitoring ports on the
I-1200 and I-2700 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.
50
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
The benefits to using 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 100 Mbps 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 (for example, 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 3-6 Tap mode
Deploying the Sensors with FE ports in internal tap mode
The 10/100/1000 (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 the following illustration) 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
51
3
Network Security Platform deployment - an overview
Sensor deployment modes
You can easily reconfigure the 10/100/1000 monitoring ports of a M-series Sensor to disable the
internal tap and monitor in In-line Mode at any time using the Manager. This process is described in
the section, Shifting from tap mode to in-line mode. When in-line, the Sensor can block malicious
traffic from reaching its intended target host.
Figure 3-7 I-2700 Sensor — Internal tap mode
52
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
Deployment of 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.
Figure 3-8 I-4000 Sensor deployed in external 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
change from the Manager interface. 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 using different ports of a Sensor. You can run one pair in in-line mode and others in tap
mode. With the GE port-Sensors, you will have to do some minimal reconnecting to convert from tap
to in-line mode.
Deployment of Sensors in in-line mode
In-line mode is achieved when the 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.
Sensors are configured by default to run in in-line mode.
When running in in-line mode, network segments are connected to two matched ports of the Sensor
(for example, ports 1A and 1B), and packets are examined in real time as they pass through the
Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
53
3
Network Security Platform deployment - an overview
Sensor deployment modes
The benefits to using 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, 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, the Sensor can drop malicious packets and not pass them through the
network. This acts sort of like an "adaptive firewall," with your detection policy dictating what is
dropped. Furthermore, when dropping packets, Network Security Platform is very precise and
granular. The Sensor can drop only those packets it identifies as malicious or all of the packets
related to that flow (a choice that is user configurable).
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. Network Security Platform only drops the
malicious packets, so spoofed traffic doesn't have the same effect.
•
54
Packet "scrubbing" -- In addition to dropping malicious traffic, Network Security Platform 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
•
Processing at wire-speed -- An obvious requirement with running in-line is to avoid dropping
packets and your IDS Sensor becoming a bottleneck. 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 3-9 In-line mode
In in-line mode (seen in the previous figure), the Sensor logically acts as a transparent repeater with
minimal latency for packet processing. Unlike bridges, routers, or switches, the Sensor does not need
to learn MAC addresses or keep an ARP cache or a routing table.
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 the figure in How complex is your network
topology? is monitoring links both inside and outside the network.
Fail-open versus fail-closed
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 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
55
3
Network Security Platform deployment - an overview
Sensor deployment modes
For more information on hardware connection, see McAfee Network Security Platform Gigabit Optical
Fail-Open Bypass Kit Guide. And, for more information on port configuration, see McAfee Network
Security Platform Manager Administration Guide.
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.
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 might restart; during
the restart, the Sensor goes into fail-open mode until it restarts. If a critical fault occurs again,
another restart cycle might be initiated. In some cases, 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 Passthru feature from the Manager user 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 Layer2 passthru mode.
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 restart 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.
High Availability
Redundancy is a key element for any network that needs to operate all the time. Using an identical
pair of Sensors (same model, software image, signature set) deployed redundantly in In-line Mode,
Network Security Platform can provide high availability with no administrator intervention.
How to understand failover in Network Security Platform
In typical failover configurations, one device is the template device while the other is the peer. As its
name implies, when you create the failover pair, the configurations applied on the template device is
applied on the peer. The template device is the active device and performs normal network functions
while the peer is the standby, which monitors, ready to take control should the template/active device
fail. When you delete the failover pair, the template device's configuration is what remains on the peer
device. So, it is recommended that you export the configuration of the peer device before you create a
failover pair.
In Network Security Platform, 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.
In the following figure, 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. One Sensor copies the packets received on its monitoring ports to the other Sensor 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.
56
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
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 3-10 Two I-4000s in a high availability configuration
Primary vs. Active
You configure a Failover Pair using the Manager. You designate one Sensor as the template Sensor and
the other as peer. 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
57
3
Network Security Platform deployment - an overview
Sensor deployment modes
This Active-Active configuration provides the added benefit of supporting asymmetric traffic flows (that
is, when packets belonging to the same TCP/UDP flow are divided across Sensors). Thus, the Network
Security Platform failover pair will detect attacks even when the traffic is asymmetric. This topic is
discussed, in the section Interface groups.
Interface groups (port clusters)
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.
Sensors' multiple interfaces make the monitoring of asymmetric traffic possible. For example, as
shown in the following figure, 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 3-11 Interface groups in an asymmetric network
Create a port cluster
The Port Clusters action enables multiple Sensor ports to be grouped together for the effective
monitoring of asymmetric environments. Asymmetric networks are common in load balancing and
active/passive configurations. Port clusters normalize the impact of traffic flows split across multiple
interfaces, thus maintaining state to avoid information loss.
58
McAfee Network Security Platform 8.1
IPS Administration Guide
3
Network Security Platform deployment - an overview
Sensor deployment modes
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.
If after initial interface group configuration you decide to change your settings, all of the previous
configurations performed for the interface group are erased in favor of the new port configuration. This
can affect sub-interfaces and policy settings.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | Setup | Advanced | Port Clusters.
Figure 3-12 Port custer list area
2
Click New.
3
Type a Name.
4
Select a Template Member Port from the drop-down list. The template member port may be a port pair
(1A and 1B) or a single port (3B). The template member port determines the policy that is
enforced by the group.
An interface changed from Dedicated to VLAN or CIDR traffic types is not eligible for interface group
combination until VLAN or CIDR IDs are added.
5
Click Next.
Figure 3-13 Create Cluster dialog
6
Select interfaces to add to the group.
7
Click New. Click Delete to remove any unwanted interfaces.
8
If interfaces are functioning as a port pair, they cannot be separated within an interface group.
Figure 3-14 Add/Delete Interfaces To Port Cluster Member dialog
McAfee Network Security Platform 8.1
IPS Administration Guide
59
3
Network Security Platform deployment - an overview
Sensor deployment modes
9
Click Save.
10 Download the changes to your Sensor by performing the steps in Updating the configuration of a
Sensor.
Managing interfaces
Sensors support four traffic types:
•
Dedicated
•
VLAN
•
Bridge VLAN (applicable only for M-series Sensors in inline mode)
•
CIDR.
By default, all interfaces monitor traffic in Dedicated mode: the interface monitors all transmissions
without regard to network segmentation. Traffic segmentation by VLAN tag or CIDR addressing is
supported. If your traffic is segmented into VLANs, for example between switches in a building, you
can change the interface type to VLAN. More commonly, if you have used CIDR addressing in your
network, changing the traffic type to CIDR helps you better protect specific networks/hosts in your
system. For VLAN and CIDR interfaces, you are able to add the network IDs, either VLAN tags or CIDR
addresses, in order to specify unique networks in your domain.
By segment the network traffic to VLAN or CIDR, the user has more flexibility in applying multiple
policies to traffic subflows. This is accomplished by configuring one or more traffic subflows (VLAN
tag(s)/CIDR block(s)) into a sub-interface.
A Bridge VLAN interface functions exactly like a VLAN interface except that post-IPS, if the traffic is
OK, the Sensor changes the VLAN ID to that of the peer ID.
The VLAN Bridging feature enables you to subject inter-VLAN traffic to IPS with the least number of
Sensors. You can also use the VLAN Bridging feature in conjunction with EtherChannel Load Balancing
on your switches, to incrementally increase the IPS bandwidth of your Network Security Platform
infrastructure.
You cannot change the traffic type of an allocated interface. Since the interface has been allocated, it is
the "virtual" property of the child domain, therefore, full ownership cannot be granted. Only the admin
domain in which the physical port(s)—thus interface—reside owns the interface and can make this type
of change.
If you decide to again change your traffic type settings after having once changed from Dedicated to
VLAN or CIDR, all of the previous configurations performed at the interface and sub-interface levels for
the interface are erased in favor of the new configuration. This can affect many scenarios including the
creation of a child admin domain to where an interface has been allocated.
60
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
3
To change the traffic type of an interface and add VLAN or CIDR network IDs, do the following:
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | IPS Interfaces | <Interface_Name> | Properties.
Figure 3-15 Manage Interface - changing traffic type
2
Select the Interface Type as one of the following:
•
Dedicated: (default) no segmentation of traffic.
•
VLAN: enables segment of interface into multiple networks by VLAN tags.
•
Bridge VLAN: enables bridging of traffic between VLANs
When the Sensor is down, the traffic is forwarded through the peer port with the same VLAN ID
with which it came to the Sensor. So, if your switches are not configured to handle such a
scenario, the packets may get dropped. You can set up a fail-over Sensor to mitigate this risk.
•
CIDR: enables segment of interface into multiple networks by CIDR addressing.
If you selected VLAN or CIDR, go to Step 3. If you selected Dedicated, you are done.
3
Click Edit from the new VLAN or CIDR window to add the VLAN/CIDR IDs.
Figure 3-16 Edit Dedicated Interface tab
McAfee Network Security Platform 8.1
IPS Administration Guide
61
3
Network Security Platform deployment - an overview
Sensor deployment modes
4
(Optional) Clear the port number(s) and type new text in the Interface Name field. The custom name
can have up to 45 alphanumeric characters including hyphens, underscores, and periods. The text
you enter appears in the Resource Tree where the interface node is located; the physical port
number is still listed in parentheses at the end of your text. For example, if you typed "VLANs 1-5"
as the Interface Name for port 2B, the Resource Tree lists the node as VLANs 1-5(2B).
If you had changed the Interface Name earlier and if you want to restore the default, Click Reset to System
Default. This action has no effect on the Description field.
If you have given a custom name to an interface and later allocated the interface to a child domain,
the custom name is not inherited by the child.
Figure 3-17 Interface name change in the Resource Tree
5
(Optional) Type an interface Description. This text does not display in the Resource Tree, only in the
interface detail. A unique description can only be entered when the interface type has been
changed to VLAN or CIDR.
Figure 3-18 Edit VLAN IDs
62
Item
Description
1
Custom name, default is port number; this name appears in Resource Tree
2
Only appears in interface description dialog
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Sensor deployment modes
6
3
Add the VLAN/CIDR IDs you want to monitor.
•
For VLAN, you can type the VLAN tags by range or by individual ID. The valid range is 0 to
4095, and the maximum number of VLAN tags per interface is 254. If you create a sub-interface
and assign all the 254 VLANs to the sub-interface, you can create more number of VLANs in the
interface.
•
For CIDR, type the network IP Address and Mask Length and click Add to List. This network address
must follow standard CIDR addressing rules (correct IP and mask length combination) to be
valid.
•
The CIDR IP address field now enables you to enter IPv4 addresses in 4 different fields
separated with dots. You can now enter the IP address value in the corresponding fields.
•
The maximum value in each field is 255. If you enter ".", you are tabbed to the next field.
•
Only numerical values between 0—9 are allowed. Special characters are not allowed.
Pressing tab after the last field tabs you to select the mask field.
If you are unsure about your exact VLAN/CIDR IDs and you do not enter IDs, you can always
add your IDs later.
Figure 3-19 Edit CIDR Interface
7
Click New to save your interface additions; click Cancel to abort.
8
Download the changes to your Sensor interface by performing the steps in Updating the
configuration of a Sensor.
Tasks
•
Delete a VLAN or CIDR ID from an interface on page 63
Delete a VLAN or CIDR ID from an interface
You can delete a VLAN or CIDR ID from a segmented interface.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | IPS Interfaces | <Interface_Name> | Properties.
2
Select the ID to delete.
3
Click Delete and confirm deletion.
4
Download the changes to your Sensor interface by performing the steps in Updating the
configuration of a Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
63
3
Network Security Platform deployment - an overview
Sensor deployment modes
Create sub-interfaces
If there is VLAN,Bridge VLAN or CIDR traffic transmitting across a monitored segment, you can create
one or more sub-interfaces. Before creating a sub-interface, the "Interface Type" must be set to VLAN
or CIDR in Managing an interface, and you must have already entered VLAN or CIDR IDs.
If you entered IDs that do not flow in the monitored link, the parent interface's policy protects all traffic.
Before creating sub-interfaces, it is important to note that you will not be able to perform the Manage DoS
IDs action at the interface level once a sub-interface is created. If you create a sub-interface, then you
must utilize Manage DoS IDs at the sub-interface level.
If you added more than one VLAN or CIDR ID to an interface, you can create a sub-interface with one
or multiple IDs or you can create multiple sub-interfaces. To create more than one sub-interface, you
must repeat the steps that follow.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | IPS Interfaces | <Interface_Name> | Sub-interface.
Figure 3-20 Manage Sub-Interface
2
Click New.
To edit an existing sub-interface, select the sub-interface and click Edit; then follow the steps below.
To delete a sub-interface, select the sub-interface and click Delete; then confirm the deletion.
3
Type a Sub-interface Name.
4
Select a policy (Policy Name) to be enforced on the sub-interface(s).
Figure 3-21 Create Sub-Interface - CIDR
64
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
How to plan your IPS deployment
5
3
Do one of the following:
•
For VLAN and Bridge VLAN move an ID from "Available" to "Allocated" by selecting the ID and
clicking the > button.
•
For CIDR, type the IP Address and Mask Length and click Add to List. A valid CIDR can be from the list
you entered at Interface-x | IPS Interface | Edit, or a CIDR host(s) within a network in your entered
list. For example, if you had entered 192.168.3.0/24, you can enter 192.168.3.1/32 and
192.168.3.2/32 here for sub-interface creation. When done adding CIDRs, click New .
The CIDR IP address field now enables you to enter IPv4 addresses in 4 different fields separated
with dots. You can now enter the IP address value in the corresponding fields.
The maximum value in each field is 255. If you enter ".", you are tabbed to next field.
Only numerical values between 0—9 are allowed. Special characters are not allowed. Pressing
tab after the last field tabs you to select mask field.
If you are creating another sub-interface from a CIDR address that has not been allocated, you
can check to see which have already been allocated by clicking List of Allocated CIDRs.
6
Click Finish.
The new sub-interface appears in the Sub-Interface List table as well as in the Resource Tree as a node
under the interface node within which it was created.
7
Download the changes to your Sensor interface by performing the steps in Updating the
configuration of a Sensor.
How to plan your IPS deployment
IPS deployment can be daunting and complex. Network Security Platform, 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.
McAfee Network Security Platform deployment can be simple or complex, depending on your needs
and your skill with the product. If you are a Beginner, you can use Network Security Platform 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
Network Security Platform includes a variety of pre-configured security policies targeting different
environments. These policies enable you to start monitoring your network right away.
McAfee Network Security Platform 8.1
IPS Administration Guide
65
3
Network Security Platform deployment - an overview
How to plan your IPS deployment
Task
1
Install the Manager as described in McAfee Network Security Platform Installation Guide.
2
The Default Inline IPS policy is applied by default. You can leave this policy in place or pick the policy
that best matches your needs. The Sensor 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.
3
Configure the Sensor and add it to the Manager as described in McAfee Network Security Platform
CLI Guide, and McAfee Network Security Platform Installation 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 information and features available in the Dashboard and Analysis pages, 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 are protected from all the critical 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. This would mean wasting the Sensor resources on things that
are not relevant for your network. 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:
66
•
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, view alerts, view the information presented in the Dashboard. 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
3
Network Security Platform deployment - an overview
Establish Sensor-to-Manager communication
Deployment scenario for advanced users
An advanced deployment of Network Security Platform utilizes more of Network Security Platform's
features to best tune your system. After you are more familiar with Network Security Platform, 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 (that is, 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.
Establish Sensor-to-Manager communication
The process of setting up a Sensor is described at a high level.
Task
1
Set up the Manager software on the server machine.
a
Install the Manager software on the server machine. For more information on this process, see
McAfee Network Security Platform Installation Guide.
b
Start the Manager software as described in McAfee Network Security Platform Manager
Administration Guide. You can establish communication with a Sensor through 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 through a browser session from a
separate client machine to perform your configuration tasks.
c
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 pre-defined Default Inline IPS policy is
applied to all of your Sensor ports upon Sensor addition.
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.
2
Use the Add Device Wizard in the Manager and add the Sensor to the required domain.
a
In the System page of the Manager, select the domain where you want to add the Sensor and
then go to Global | Add Device Wizard.
b
Make sure you have the information mentioned in the Add Device Wizard page click Next.
c
Specify the required information in the Add New Device page.
•
Enter the Device Name. This must be the same name (case-sensitive) that you assigned to
the Sensor through Sensor CLI.
•
Select IPS Sensor or NTBA Appliance as the Device Type.
McAfee Network Security Platform 8.1
IPS Administration Guide
67
3
Network Security Platform deployment - an overview
Configure your deployment using the Manager
3
•
Enter and confirm the Shared Secret key. You must enter the same key (case-sensitive) in
the Sensor CLI when you establish Sensor-to-Manager communication.
•
If required, specify the information for the optional fields.
•
Click Next and click Check Trust.
Configure the Sensor.
•
From a serial console connected physically or logically to the Sensor, configure the Sensor with
network identification information (that is, 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 more information on configuring the Sensor using the Sensor CLI, see McAfee Network
Security Platform CLI Guide.
4
5
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 the Sensor's name is listed. In the System page of the
Manager select the corresponding domain and then check if the Sensor is listed in the Device
drop-down.
Troubleshoot any problems you run into.
•
6
If you run into any problems, check your configuration settings, and ensure that they are
correct. For more troubleshooting tips, see McAfee Network Security Platform Troubleshooting
Guide.
Verify the operating mode of the ports on your Sensor.
•
Your 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 set up the Sensor to
monitor in in-line mode, check your settings to make sure everything is correct.
Configure your deployment using the Manager
After 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:
68
•
Apply IPS policies to each interface of your multi-port Sensor (instead of applying one
policy to all interfaces, as when you chose the default policy to establish
Sensor-to-Manager communication). You can ensure all of your interfaces use IPS 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. More information on the provided policies is available in the subsequent
sections.
•
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 Network
Security Platform 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 for a host.
•
Filter alerts. An exception object 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 exception objects, see McAfee Network Security Platform
Manager Administration Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
View and work with data generated by Network Security Platform
3
•
View the system's health. The Operational Status page details the functional status for all of your
installed Network Security Platform system components. Messages are generated to detail system
faults experienced by your Manager, Sensors, or database. For more information, see McAfee
Network Security Platform Manager Administration 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.
•
Back up all or part of your Manager configuration information to your server or other location.
Network Security Platform provides three backup options:
•
All Tables -- all Network Security Platform data (configuration, audit, and alert).
•
Config Tables -- all information related to system configuration, such as port configuration, users,
admin domains, policies for all Network Security Platform 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 types of backups to an
alternate location.
For more information on how to back up your data, see McAfee Network Security Platform Manager
Administration Guide.
View and work with data generated by Network Security
Platform
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 and other data for traffic that is in
violation of the set security policy.
The Manager processes all the information that it receives from your Sensors and presents them in a
form that is readily understandable to you. The Dashboard displays the information in a graphical
format, whereas the Analysis page displays the information in a tabular format.
•
The Real-time and Historical Threat Analyzers 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 can access
these Threat Analyzers from the Analysis page. You use the Threat Analyzer to perform forensic
analysis on the alert to help you tune the Network Security Platform system, provide better
responses to attacks, and otherwise shore up your defenses. You can start the Threat Analyzer for
specific admin domains.
•
The Reports Main page provides you detailed reports based on your alerts, and reports on your
Network Security Platform configuration. You can use these reports to communicate incidents to
other members of your team and to your management.
For more information on these tools, see McAfee Network Security Platform Manager Administration
Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
69
3
Network Security Platform deployment - an overview
Tune your deployment
Tune your deployment
Once you become familiar with the basics of the Manager program, you can further enhance your
deployment by utilizing some of the more advanced features. These features include:
•
Cloning and modifying the Network Security Platform-provided policy. This information is
provided in the subsequent sections.
•
Deploying your Sensor to monitor traffic in Tap mode or, ultimately, in In-line mode.
•
Adding users and assigning management roles. For more information, see Managing Users in
Network Security Platform, McAfee Network Security Platform Manager Administration Guide..
•
Adding admin domains for resource management. For more information, see Administrative
Domains, McAfee Network Security Platform Manager Administration Guide.
•
Changing your interface type to CIDR or VLAN depending on your network configuration.
•
Using other features such as Firewall to block traffic or pass traffic without sending it
through the IPS engine.
Update 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 McAfee® Network Security Update Server to registered support
customers.
Figure 3-22 Update signatures and software
70
Field
Description
1
Update Server
2
Internet
McAfee Network Security Platform 8.1
IPS Administration Guide
Network Security Platform deployment - an overview
Update your signatures and software
Field
Description
3
Manager Server
4
PC/tftp server
5
Import/disk
6
Sensor
3
Manager software installation includes a default signature set image.
There are several options for loading updates to your Manager and Sensors.
1
Download images from the McAfee Network Security Update Server (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. For more
information, see McAfee Network Security Platform Manager Administration 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:
3
•
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. For more information, see McAfee Network Security Platform Manager
Administration 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.
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. For more information on this method, see McAfee Network Security Platform CLI
Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
71
3
Network Security Platform deployment - an overview
Update your signatures and software
72
McAfee Network Security Platform 8.1
IPS Administration Guide
4
Configuring the monitoring and response
ports of a Sensor
Contents
Configuration of device monitoring and response ports
Hardware for monitoring ports
Configuration of monitoring ports
Configure response ports
View management port settings
Configuration of device monitoring and response ports
The Monitoring Ports action enables you to view/edit the parameters of the monitoring and response ports
on a specific device. Monitoring port configuration allows you to change device deployment modes,
select port speeds or indicate whether you are using McAfee certified modules, enable/disable ports,
and choose the path for device responses. Response port configuration allows you to choose the
receiving device and change the link speed. Port Settings are configured using the virtual device action
buttons available against within every device settings page in the Manager UI.
The following table contains the default values for device ports in different operating modes. You must
ensure that the switch or router ports connected to the device ports match these settings for the
configurations as shown:
Interface Type
Mode
Auto-negotiation
Speed
Duplex
40 Gigabit Ethernet
Tap
OFF
N/A
N/A
40 Gigabit Ethernet
SPAN
OFF
N/A
N/A
40 Gigabit Ethernet
In-line
OFF
N/A
N/A
10 Gigabit Ethernet
Tap
OFF
N/A
N/A
10 Gigabit Ethernet
SPAN
OFF
N/A
N/A
10 Gigabit Ethernet
In-line
OFF
N/A
N/A
Gigabit Ethernet
Tap
OFF
N/A
N/A
Gigabit Ethernet
SPAN
ON
N/A
N/A
Gigabit Ethernet
In-line
ON
N/A
N/A
Fast Ethernet
Tap
OFF
Configurable
Half-duplex
Fast Ethernet
SPAN
OFF
Configurable
Configurable
Fast Ethernet
In-line
OFF
Configurable
Configurable
McAfee Network Security Platform 8.1
IPS Administration Guide
73
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
Ports for I-Series devices
The device graphics on the Port Settings page displays a graphical representation of the number of ports
available for the device you selected. Following is a port description for the Sensors.
•
I-4010, I-3000: twelve detection ports and two response ports.
•
I-4000: four detection ports and two response ports.
•
I-2700: eight detection ports (six Fast Ethernet and two Gigabit Ethernet) and three response
ports.
•
I-1400: four detection ports and one response port.
•
I-1200: two detection ports and one response port.
The color-coded table to the right of the ports lists the administrative and Operational Status of the
port.
The following images show ports of I-series devices.
Ports for I-4010 device
Ports for I-4000 device
Ports for I-3000 device
74
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
4
Ports for I-2700 device
Ports for I-1400 device
Ports for I-1200 device
McAfee Network Security Platform 8.1
IPS Administration Guide
75
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
Virtual device action buttons
There are three important buttons on the virtual device aside from the Monitoring and Response ports.
Descriptions of these buttons are given below:
•
Commit Changes: saves configuration changes for subsequent push from Manager to device when the
configuration is updated (Update Configuration). For example, if you changed monitoring port 1A
from being part of a port pair in Tap Mode to a single port in SPAN or Hub Mode, clicking Commit Changes
queues this information for download to the device. You must also connect your segments correctly
to the device for this change to be successful.
•
Cancel Changes: reverts all configuration changes back to the way they were before the most recent
changes. For example, if you changed monitoring port 1A from being part of a port pair group in
Tap Mode to a single port in SPAN or Hub Mode, and you changed your mind after clicking OK in
monitoring port configuration, clicking Cancel Changes clears your most recent changes to the
previous settings.
You must click Cancel Changes before clicking Commit Changes in order to effectively remove recent
changes.
•
Refresh: sends a poll from Manager to device and back detailing the most current state of the
interfaces on the device. For example, if you disconnected a cable from monitoring port 1A (and
this port was previously Enabled) and click Refresh in the UI, port 1A in the virtual device changes
from green to red.
If, after initial port configuration, you decide to change your port settings, all of the previous
configurations performed at the interface and sub-interface levels are erased in favor of the new
port configuration. This will erase such information as interface traffic types and child admin
domains where interfaces were allocated for management.
Ports for M-series devices
To view or configure the settings of the monitoring ports for McAfee Network Security Platform
M-series devices, you access the configuration page in the same manner as required for the I-series
devices (<Admin Domain Name> | Device List | <Device_Name> | Physical Ports).
A page is displayed with the list of ports available for the device you selected. Following is a port
description for the Sensors.
76
•
M-8000: twenty eight detection ports (sixteen 10/100/1000 SFP ports and twelve 10 Gigabit
Ethernet XFP ports) and one response port.
•
M-6050: sixteen detection ports (eight 10/100/1000 SFP ports and eight 10 Gigabit Ethernet XFP
ports) and one response port.
•
M-4050: twelve detection ports (eight 10/100/1000 SFP ports and four 10 Gigabit Ethernet XFP
ports) and one response port.
•
M-3050: twelve detection ports (eight 10/100/1000 SFP ports and four 10 Gigabit Ethernet XFP
ports) and one response port.
•
M-2750: twenty detection ports (twenty 10/100/1000 SFP ports).
•
M-1450: eight detection ports and one response port.
•
M-1250: eight detection ports and one response port.
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
4
The following image diaplays the port details for M-8000.
Figure 4-1 Ports for M-8000
McAfee Network Security Platform 8.1
IPS Administration Guide
77
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
The following image displays the port details for M-6050.
Figure 4-2 Ports for M-6050
The following image displays the port details for M-4050.
Figure 4-3 Ports for M-4050
78
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
4
The following image displays the port details for M-3050.
Figure 4-4 Ports for M-3050
The following image displays the port details for M-2750.
Figure 4-5 Ports for M-2750
The following image displays the port details for M-1450.
Figure 4-6 Ports for M-1450
McAfee Network Security Platform 8.1
IPS Administration Guide
79
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
The following image displays the port details for M-1250.
Figure 4-7 Ports for M-1250
Ports for NS-series Devices
To view or configure the settings of the monitoring ports for McAfee Network Security Platform
NS‑series devices, you access the configuration page in the same manner as required for the M‑series
devices (Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports).
80
McAfee Network Security Platform 8.1
IPS Administration Guide
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
A page is displayed with the list of ports available for the device you selected. Following is a port
description for the Sensors.
•
NS9100: Ten fixed detection ports (eight RJ‑45 10/100/1000 Mbps Ethernet Monitoring ports and
two QSFP+ 40 Gigabit Ethernet ports.
10 Gigabit Ethernet ports (modular up to 16) and 40‑Gigabit Ethernet ports ( modular up to 4).
One response port.
•
NS9200: Ten fixed detection ports (eight RJ‑45 10/100/1000 Mbps Ethernet Monitoring ports and
two QSFP+ 40 Gigabit Ethernet ports.
10 Gigabit Ethernet ports (modular up to 16) and 40‑Gigabit Ethernet ports ( modular up to 4).
One response port.
•
NS9300: Sixteen fixed detection ports (eight RJ‑45 10/100/1000 Mbps Ethernet Monitoring ports.
10 Gigabit Ethernet ports (modular up to 32) and 40‑Gigabit Ethernet ports ( modular up to 16).
One response port.
Figure 4-8 Ports for NS9200
Monitoring Port details
The following are the details of the monitoring ports displayed in the Monitoring Ports tab.
Table 4-1
Monitoring Port details
Column
Description
Port
Specifies the monitoring port.
Link
Specifies the status of the monitoring port. The available status are:
• Up
• Down
• Disabled
Connector Type Displays the connector type.
McAfee Network Security Platform 8.1
IPS Administration Guide
81
4
Configuring the monitoring and response ports of a Sensor
Configuration of device monitoring and response ports
Table 4-1
Monitoring Port details (continued)
Column
Description
Speed
Specifies the speed of the port. The following are the available speed:
• Auto-negotiate
• 10 Mbps(full)
• 1 Gbps(full)
• 10 Mbps(half)
• 100 Mbps(full)
• 10 Gbps(full)
• 100 Mbps(half)
• 40 Gbps(full)
Operation
Mode
Specifies the mode of operation. The following are the available modes:
• Inline Fail-Open - Active
• SPAN or Hub
• Inline Fail-Open - Passive
• Tap
• Inline Fail-Closed
Fail-Open Kit
Displays the status of the fail open kit. The following are the available status:
• Present
• Built in
• Unknown
• n/a
Placement
Displays the area of the network where the port is connected. The options are:
• Inside Network
• Outside Network
Response Port
Specifies the path of response for the device. The available options are:
• This port
• R1
• R2
Display options for Monitoring ports
You have the following options to view the details of the list of monitoring ports:
•
Show all ports - To display the list of all monitoring ports
•
Hide empty slots - To hide ports that have empty slots and display only those ports that are
configured.
Enable or disable a monitoring port
This section explains about enabling and disabling a monitoring port from the Montitoring Port tab.
To view or configure the settings of the monitoring ports for McAfee Network Security Platform, you
access the configuration page in<Admin Domain Name> | Device List | <Device_Name> | Physical Ports. A list of
ports available for the device you selected are displayed in the Monitoring Port tab of a new page.
82
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Hardware for monitoring ports
4
To disable a monitoring port:
1
Click on the row of the monitoring port that you wish to disable.
To disable multiple monitoring ports, press the Shift key and click on multiple monitoring ports that
you wish to disable.
2
Click on the Disable button. The monitoring port(s) are disabled.
To enable a monitoring port:
1
Click on the row of the monitoring port that you wish to enable.
To enable multiple monitoring ports, press the Shift key and click on multiple monitoring ports that
you wish to enable.
2
Click on the Enable button. The monitoring port(s) are enabled.
Port color key
This section describes a port's status color under the Link column in the Collection Ports tab.
Table 4-2
Port color key
Color
Description
Green
Port is enabled and operating correctly.
Red
Port is enabled, but not operating due to some failure. Check system faults.
Gray
Port has been disabled by the user.
Orange Device or NTBA Appliance is disconnected. The port data is retrieved from the database.
Beige
Port has been modified.
Hardware for monitoring ports
Before you configure the monitoring and response ports of a physical Sensor, make sure you have
correctly cabled the ports as per your network design and requirements. Based on the Sensor model
and the port that you plan to use, you might be required to connect some hardware to the monitoring
ports. This section introduces the various hardware that might be required to configure monitoring
ports.
•
Transceivers — Based on the Sensor model, monitoring ports use different types of transceivers to
connect to peer devices. The transceiver types that are supported as follows:
•
Small Form-factor Pluggable (SFP) (fiber or Copper)
•
10GbE Small Form-factor Pluggable (XFP) (applicable only for M-series Sensors)
•
SFP+ (applicable only for NS-series Sensors)
•
QSFP+ (applicable only for NS-series Sensors)
Refer to the corresponding Sensor product guide to know the transceivers type used by the
monitoring ports and how to cable them.
McAfee Network Security Platform 8.1
IPS Administration Guide
83
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
•
Fail-open kits — Fiber monitoring ports are fail-closed by default; thus, if these ports are deployed
in-line, a Sensor hardware failure, for example, results in network downtime. Fail-open operation
for fiber ports requires the use of the an external bypass switch. Fail-open bypass kits minimize the
potential risks of in-line Sensor failure on critical network links. There are two types of fail-open
kits available - active and passive. To know the difference between the two and to know the active
and passive fail-open kits that are available, see Using active fail-open kits, Network Security
Platform Best Practices Guide. For information on how to deploy a particular fail-open kit, refer to
the corresponding guide. For example, for information on how to deploy gigabit optical Active
fail-open switch, see the 1 Gigabit Optical Active Fail-Open Bypass Kit Guide.
•
External tap device, if you plan to deploy monitoring ports in the tap mode. See Deployment of
Sensors in tap mode.
Configuration of monitoring ports
Configuration of monitoring ports enables you to set the operating mode of your ports, change port
speeds or specify whether you are using McAfee certified modules, and/or choose the corresponding
response port for device action.
For information on properly connecting your device for the various operating modes, see the
appropriate McAfee Network Security Platform <Sensor > Product Guide.
Configure ports for I-Series devices
You can view or configure the settings of the monitoring ports for the Sensor.
84
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
4
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Monitoring Ports.
2
Click a numbered port (for example, 1A) from Monitoring Ports. A pop-up displays current port
settings.
Figure 4-9 Configure Monitoring Port: 1A window
3
Select the Speed of the port. Port speed details the speed of traffic being monitored.
For I-3000 and I-4010 device models, you can select the following speed setting values from the
drop-down list.
•
10 Mbps
•
100 Mbps
•
1 Gbps
The Gigabit Ethernet (GE) ports support either 1 Gbps or Auto Negotiate (default). The Fast Ethernet
(FE) ports support 10 Mbps or 100 Mbps (default).
McAfee Network Security Platform 8.1
IPS Administration Guide
85
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
For I-3000 and I-4010 device models, you need to connect copper SFPs to support
10/100/1000/10-auto/100-auto/1000-auto speed settings. The LED link will turn green if speed is
set to 10 Mbps or 100 Mbps value.
Figure 4-10 Configure Monitoring Port: 3A window
You can use the show command in device CLI to view the settings. FE settings cannot be configured
from the CLI.
Performing a resetconfig or factorydefaults on the device will reset the port speed to 1 Gbps. If
you plan to configure the port speed to 10 Mbps, you must also set all of the ports on the
connecting network device (switch, hub, etc) to 10 Mbps. A mixed speed configuration may cause
malfunction.
4
Select the Duplex mode as Full or Half. The duplex mode relates to the connection monitored by the
interface. If connected to a SPAN or hub or if you deploy an external tap configuration, the default
mode is Half-duplex. If connected in Tap or In-line mode, Full-duplex is the default.
5
Select the Administrative Status as either Enable (on) or Disable (off). Accordingly the Operational
Statusdisplays Up (on) or Down (off).
If your Operational Status displays as Downand yourAdministrative Status is Enabled, there may be a problem.
Check the Operational Status for more information.
86
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
6
4
Select an Operating Mode from the following:
Your device connections must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-open (Port Pair)
•
In-line Fail-close (Port Pair)
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
Auto Negotiate is enforced for In-line Fail-open (Port Pair) when Copper Fail-Open kit is used
with port speed set to 10 Mbps and 100 Mbps.
•
Tap (Port Pair)
For FE ports configured in Tap (Port Pair) mode, select External if using an external tap, or Internal
if using the internal tap feature. GE ports can only be configured for External Tap mode.
If FE ports fail when configured in Internal Tap Mode, traffic will continue to pass. However, your
device will experience some latency that may block traffic upto a minute before the passthru is
established.
Figure 4-11 Configure Monitoring Port: 2A window
•
SPAN or Hub (single port)
McAfee Network Security Platform 8.1
IPS Administration Guide
87
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port 1A is
configured for Tap mode, port 1B is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example 1A-1B make up a port pair. However, 1A-2B cannot be a port pair.
For more information on the deployment modes of the Sensors, McAfee Network Security Platform
IPS Administration Guide.
7
Select the area of your network where the current port is connected: Inside (internal) or Outside
(external) your network. This step applies to Tap or In-line modes only.
8
Wherever applicable, select a Response Mode, including the specific Response Port Number. The response
mode defines the path of response of the device. The following choices are available:
•
Send Response From This Port: respond out of the detection port to the segment. This is selected by
default for In-line and SPAN operating modes.
•
Use Specified Response Port: sends responses through a designated response port. Choose from the
available response ports on the current device. (For example, I-1200 has one response port,
I-4000 has two response ports.) This response option is selected by default for External Tap
operating mode.
You can assign a response port to more than one device monitoring port. However, knowing
where your response ports are connected in the network will make for the best response system.
9
Click OK.
10 Click Save save the changes.
A confirmation page is displayed.
Figure 4-12 Informational Message dialog
11 Download the changes to your device by performing the steps in Updating the configuration of a
device.
Configuration of ports for M-series devices
To view or configure the settings of the monitoring ports for McAfee Network Security Platform
M-series devices, you access Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
The M-series devices require configuration of XFP and SFP Monitoring ports—with certain guidelines
regarding the type and functionality of the module.
McAfee supports only those XFP/SFP modules purchased through McAfee or from a McAfee-approved
vendor.
Donot use XC ports. These ports are reserved for interconnection between the Primary device (M-8000
P) and Secondary device (M-8000 S).
Configure 10 Gbps (XFP) monitoring ports
You can view or configure settings for the 10 Gbps monitoring ports.
88
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
4
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of the monitoring port that displays the Connector Type as XFP. The Port
Details window is displayed.
Figure 4-13 Configure Monitoring Port window
The speed is automatically set to 10 Gbps on the 10 Gigabit Ethernet ports. However, you can specify
whether the modules are McAfee Certified.
3
Select the State as either Enabled (on) or Disabled (off). Accordingly the Linkdisplays Up (on) or Down
(off).
If your Link displays as Down and yourState is Enabled, there may be a problem. Check the Operational
Status for more information.
4
Select an Mode from the following:
Your device cabling must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-Open - Active
•
In-line Fail-Open - Passive
McAfee Network Security Platform 8.1
IPS Administration Guide
89
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
•
In-line Fail - Closed
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
•
Tap (port pair)
For FE ports configured in Tap (Port Pair) mode, select External if using an external tap, or Internal
if using the internal tap feature. GE ports can only be configured for External Tap mode.
If FE ports fail when configured in Internal Tap Mode, traffic will continue to pass. However, your
device will experience some latency that may block traffic upto a minute before the passthru is
established.
•
SPAN or Hub (single port)
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port 1A is
configured for Tap mode, port 1B is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example 1A-1B make up a port pair. However, 1A-2B cannot be a port pair.
For more information on the deployment modes of the Sensors, see McAfee Network Security
Platform IPS Administration Guide.
5
Select Placement of your network where the current port is connected: Inside Network or Outside Network .
This step applies to Tap or In-line modes only.
6
Wherever applicable, select a Response Port.The following choices are available:
•
This Port: respond out of the detection port to the segment. This is selected by default for In-line
and SPAN operating modes.
•
R1: sends responses through a R1 port.
•
R2: sends responses through a R2 port.
You can assign a response port to more than one device monitoring port. However, knowing where
your response ports are connected in the network will make for the best response system.
7
Click Save to save changes. A window is displayed to confirm the changes. Click OK to confirm
changes.
Configuring 1 Gbps (SFP) Monitoring Ports
You can view or configure settings for the 1 Gbps monitoring ports.
90
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
4
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of the monitoring port that dispalys the Connector Type as SFP. The Port
Details window is displayed.
Figure 4-14 View Monitoring Port window
3
Select the Speed of the port. Port speed details the speed of traffic being monitored. You can set the
port speed by selecting from the following values on the drop down list:
•
Auto-Negotiate
•
1 Gbps/(full)
•
100 Mbps(full)
•
100 Mbps(half)
•
10 Mbps(full)
•
10 Mbps(half)
The LED link will turn green if the speed is set to 10 Mbps or 100 Mbps.
4
Specify whether a McAfee Certified SFP type should be used.
5
Select the State as either Enabled (on) or Disabled (off). Accordingly the Linkdisplays Up (on) or Down
(off).
If your Link displays as Downand yourState is Enabled, there may be a problem. Check the Operational
Status for more information.
McAfee Network Security Platform 8.1
IPS Administration Guide
91
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
6
Select an Mode from the following:
Your device cabling must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-Open - Active
•
In-line Fail-Open - Passive
•
In-line Fail - Closed
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
•
Tap (port pair)
For FE ports configured in Tap (Port Pair) mode, select External if using an external tap, or Internal
if using the internal tap feature. GE ports can only be configured for External Tap mode.
If FE ports fail when configured in Internal Tap Mode, traffic will continue to pass. However, your
device will experience some latency that may block traffic upto a minute before the passthru is
established.
•
SPAN or Hub (single port)
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port 1A is
configured for Tap mode, port 1B is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example 1A-1B make up a port pair. However, 1A-2B cannot be a port pair.
For more information on the deployment modes of the Sensors, see McAfee Network Security
Platform IPS Administration Guide.
7
Select Placement of your network where the current port is connected: Inside Network or Outside Network .
This step applies to Tap or In-line modes only.
8
Wherever applicable, select a Response Port.The following choices are available:
•
This Port: respond out of the detection port to the segment. This is selected by default for In-line
and SPAN operating modes.
•
R1: sends responses through a R1 port.
•
R2: sends responses through a R2 port.
You can assign a response port to more than one device monitoring port. However, knowing where
your response ports are connected in the network will make for the best response system.
9
Click Save to save changes.
Configuration of ports for NS-series devices
To view or configure the settings of the monitoring ports for McAfee Network Security Platform
NS‑series devices, you access the configuration page in the same manner as required for the M‑series
devices (Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports).
Configure 40 Gbps (QSFP+) monitoring ports
Configuration of monitoring ports enables you to set the operating mode of your ports, change port
speeds or specify whether you are using McAfee certified modules, and/or choose the corresponding
response port for device action.
92
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
4
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of numbered 40 Gbps (QSFP+) monitoring port.The Monitoring Port Details
window is displayed.
Figure 4-15 Configure Monitoring Port window
The speed is automatically set to 40 Gbps on the 40 Gigabit Ethernet ports. However, you can specify
whether the modules are McAfee Certified.
3
Select the State as either Enabled (on) or Disabled (off). Accordingly the Linkdisplays Up (on) or Down
(off).
If your Link displays as Down and yourState is Enabled, there may be a problem. Check the Operational
Status for more information.
4
Select a Mode from the following:
Your device connections must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-Open - Active
•
In-line Fail-Open - Passive
McAfee Network Security Platform 8.1
IPS Administration Guide
93
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
•
In-line Fail - Closed
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
•
Tap (port pair)
GE ports can only be configured for External Tap mode.
•
SPAN or Hub (single port)
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port G2/1 is
configured for Tap mode, port G2/2 is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example G2/1-G2/2 make up a port pair.
For more information on the deployment modes of the Sensors, see McAfee Network Security
Platform IPS Administration Guide.
5
Select Placement of your network where the current port is connected: Inside Network or Outside Network .
This step applies to Tap or In-line modes only.
6
Wherever applicable, select a Response Port.The following choices are available:
•
This Port: respond out of the detection port to the segment. This is selected by default for In-line
and SPAN operating modes.
•
R1: sends responses through a R1 port.
•
R2: sends responses through a R2 port.
You can assign a response port to more than one device monitoring port. However, knowing where
your response ports are connected in the network will make for the best response system.
7
Click Save to save changes.
A confirmation page is displayed. A window is displayed to confirm the changes. Click OK to confirm
changes.
Configure 10 Gbps (SFP+) Monitoring Ports
You can view or configure settings for the 10 Gbps monitoring ports.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of numbered 10 Gbps (SFP+) monitoring port.The Monitoring Port Details
window is displayed.
The speed is automatically set to 10 Gbps on the 10 Gigabit Ethernet ports. However, you can specify
whether the modules are McAfee Certified.
3
Select the State as either Enabled (on) or Disabled (off). Accordingly the Linkdisplays Up (on) or Down
(off).
If your Link displays as Down and yourState is Enabled, there may be a problem. Check the Operational
Status for more information.
94
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
4
4
Select a Mode from the following:
Your device connections must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-Open - Active
•
In-line Fail-Open - Passive
•
In-line Fail - Closed
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
•
Tap (port pair)
GE ports can only be configured for External Tap mode.
•
SPAN or Hub (single port)
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port G2/1 is
configured for Tap mode, port G2/2 is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example G2/1-G2/2 make up a port pair.
For more information on the deployment modes of the Sensors, see McAfee Network Security
Platform IPS Administration Guide.
5
Select Placement of your network where the current port is connected: Inside Network or Outside Network .
This step applies to Tap or In-line modes only.
6
Wherever applicable, select a Response Port.The following choices are available:
•
This Port: respond out of the detection port to the segment. This is selected by default for In-line
and SPAN operating modes.
•
R1: sends responses through a R1 port.
•
R2: sends responses through a R2 port.
You can assign a response port to more than one device monitoring port. However, knowing where
your response ports are connected in the network will make for the best response system.
7
Click Save to save changes.
A confirmation page is displayed. A window is displayed to confirm the changes. Click OK to confirm
changes.
Configure 1 Gbps (SFP) Monitoring Ports
You can view or configure settings for the 1 Gbps monitoring ports.
McAfee Network Security Platform 8.1
IPS Administration Guide
95
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of numbered 1 Gbps(SFP) port. The Monitoring Port Details window is displayed.
Figure 4-16 View Monitoring Port window
3
4
Select the Speed(Duplex) of the port. Port speed details the speed of traffic being monitored. You can
set the port speed to from the following values on the drop down list:
•
Auto-Negotiate
•
1 Gbps(full)
•
100 Mbps(full)
•
100 Mbps(Half)
•
10 Mbps(full)
•
10 Mbps(Half)
Select the State as either Enabled (on) or Disabled (off). Accordingly the Link displays Up (on) or Down
(off).
If your Link displays as Down and your State is Enabled, there may be a problem. Check the Operational
Status for more information.
96
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
5
4
Select a Mode from the following:
Your device connections must match the selected operating mode for correct system functionality.
Improper deployment may result in system faults, including missed attacks and system failure.
•
In-line Fail-Open - Active
•
In-line Fail-Open - Passive
•
In-line Fail - Closed
In-line Fail-open and In-line Fail-closed are determined by how the port cables are connected.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Optical Fail-Open Bypass Kit (sold separately). You should not select the In-line Fail-Open
option if the optional external Bypass Switch is not present.
•
Tap (port pair)
GE ports can only be configured for External Tap mode.
•
SPAN or Hub (single port)
If a port is functioning as part of a Port Pair, the Peer Port is listed. For example, if port G2/1 is
configured for Tap mode, port G2/2 is listed as the Peer Port. All ports are wire-matched internally
with a single peer, for example G2/1-G2/2 make up a port pair.
For more information on the deployment modes of the Sensors, see McAfee Network Security
Platform IPS Administration Guide.
6
Select Placement of your network where the current port is connected: Inside Network or Outside Network .
This step applies to Tap or In-line modes only.
7
Wherever applicable, select a Response Port.The following choices are available:
•
This Port: respond out of the detection port to the segment. This is selected by default for In-line
and SPAN operating modes.
•
R1: sends responses through a R1 port.
•
R2: sends responses through a R2 port.
You can assign a response port to more than one device monitoring port. However, knowing where
your response ports are connected in the network will make for the best response system.
8
Click Save to save changes.
A confirmation page is displayed. A window is displayed to confirm the changes. Click OK to confirm
changes.
Configuration of gigabit ethernet in-line fail-open status
When deploying your Gigabit Ethernet ports in In-line Fail-open mode, you must verify cable connections
and status of the optical bypass switch and compact flash controller, which are required for this
functionality.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the Gigabit
Fail-Open Bypass Kits (sold separately).
For more information on steps on properly connecting your Sensor for GE In-line Fail-Open functionality,
see McAfee Network Security Platform Installation Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
97
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
When configuring Gigabit Ethernet ports in In-line Fail-open mode, you must answer the following
prompts:
98
•
Confirmation 1: bypass connection confirmation. Confirm whether (Yes) or not (No) you have already
connected the required bypass switch and compact flash controller.
•
Confirmation 2: handling of TCP flow violations. Confirm whether you want to permit (Yes) or drop (No)
violating packets.
McAfee Network Security Platform 8.1
IPS Administration Guide
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
•
Verify Configuration: bypass switch status verification. Next to the Operating Mode field, check the status
of the port pair as well as the bypass switch (Switch). Refer to the table for status fields.
Figure 4-17 Verify configuration
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the Gigabit
Fail-Open Bypass Kits. You should not select the In-line Fail-Open option if the optional external Bypass
Switch is not present.
McAfee Network Security Platform 8.1
IPS Administration Guide
99
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
•
Verify Status on Virtual Device: fail-open status verification. Once you have configured a GE port pair for
fail-open functionality, view the current status under each applicable port pair on the virtual device:
the I-4000 has 2 pairs (1A-1B and 2A-2B).
The fail-open status on the virtual device is only seen when in-line fail-open mode has been
configured.
Figure 4-18 Verify status
The port status and operating mode status for GE In-line Fail-open mode are detailed as follow:
100
In-line fail-open
port status
Operating mode status
In-line Fail-Open
The in-line fail-open device is in in-line fail-open mode.
In-line Bypass
The in-line fail-open device is in in-line bypass mode. The bypass switch has
been activated. The device does not monitor during this time.
Unknown
Unable to get the status of the in-line fail-open device from device. Check the
Operational Status.
Switch Absent
Fail-open controller is not present, controller cable is not present, or optical
bypass switch is not present. Verify that all three components are connected
properly. If everything is connected correctly, check the Operational Status.
N/A
Not Applicable; the operating mode is not in in-line fail-open mode.
McAfee Network Security Platform 8.1
IPS Administration Guide
4
Configuring the monitoring and response ports of a Sensor
Configuration of monitoring ports
Change a monitoring port from single port to a port pair mode
You must disable both ports required for port pair operation when changing the Operating Mode from
SPAN or Hub Mode to a port pair (Tap or In-line) mode. device monitoring ports are configured by
default to operate in SPAN or Hub mode.
Changing from one port pair mode to another port pair mode does not require disabling of ports.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of the port to be configured. The Port Details page is displayed.
3
Select Disabled from the State drop-down list.
4
Click Save.
5
Select the peer port, for example, 1B.
6
Select Disabled at the State drop-down list.
7
Select Tap or In-line Fail-Open mode as the Mode.
8
Click Enabled at State.
9
Configure your port settings (port speed or McAfee certification, duplex, response port usage).
10 Click Save.
11 Select port 1A to verify the State reads Enabled and the Mode matches your new setting.
12 Click Save.
Change a monitoring interface from external tap to in-line (and
vice versa)
You can change your monitoring configuration from External Tap mode to In-line mode, or you can
change from In-line Mode back to External Tap mode.
Task
1
Disconnect the segments from the external tap and connect the segments appropriately to your
device port pair.
If going from an In-line mode to External Tap mode, disconnect the segments from the device and
connect the segments appropriately to the external tap and device ports.
2
Go to Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
3
Double click on the row of the monitoring port to be configured, example, 1A. The Port Details page is
displayed.
4
Select an In-line Fail-Open mode as the Mode.
Select Tap as the Mode if going from In-line to External Tap mode. For Fast Ethernet ports, you will
need to select External Network from the Placement field.
5
Configure port settings (port speed or McAfee certification, duplex, response port setting—you will
need to select a response port if changing from In-line Mode to Tap Mode).
6
Click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
101
4
Configuring the monitoring and response ports of a Sensor
Configure response ports
Change from internal tap mode to in-line fail-close mode for
fast ethernet monitoring ports
The time will come when you want to change from Tap mode to In-line mode in order to start dropping
attacking packets. This configuration can be performed without any manual intervention (that is,
changing cable connections) if you change from Internal Tap mode to In-line Fail-closed mode (Fast
Ethernet monitoring ports only).
The following procedure assumes the present configuration is Internal Tap mode.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Double click on the row of the monitoring port to be configured, example, 1A. The Port Details
page is displayed.
3
Select In-line Fail-Closed mode as the Mode.
4
Configure port settings (port speed or McAfee certification, duplex, response port setting).
5
Click Save.
Configure response ports
Utilizing device response ports enables your device to send preset responses (enabled in policy
configuration), such as a TCP reset, as well as post-detection responses, such as firewall blocking of
traffic, upon detection of malicious traffic. The device response ports are most commonly used with an
external tap operating configuration. The other operating modes allow responses to be injected back
through the interface ports. Since responses cannot be injected into a segment through an external
tap, response port configuration is necessary.
Task
102
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Click on the Response Ports tab.
McAfee Network Security Platform 8.1
IPS Administration Guide
4
Configuring the monitoring and response ports of a Sensor
Configure response ports
3
Double click on the row of the response port to be configured. The Response Port Details window is
displayed.
Figure 4-19 Configure Response Port window
4
Select a Speed(Duplex). The following are the options. Choices are Auto Negotiate, 10 Mbps, or 100 Mbps
(default).
•
Auto-Negotiate
•
10 Mbps(full)
•
1 Gbps(full)
•
10 Mbps(half)
•
100 Mbps(full)
•
10 Gbps(full)
•
100 Mbps(half)
If you plan to configure the Port Speed to 10 Mbps, you must also set all of the ports on the
connecting network device (switch, hub, and so on) to 10Mbps. A mixed speed configuration may
cause malfunction. The duplex mode relates to the connected network device. If connected to a hub,
the mode should be half-duplex. If connected to a switch or router, the mode is typically full-duplex.
5
Select the State as either Enabled (On) or Disabled (Off). For example, you need to Disable the port if
you connect a new wire, then Enable it after re-connection.
6
Select the network component the response port connects to (Connected To): either aSwitch or a
Router.
•
7
If you select Router, in the Virtual MAC Address type the MAC address of the router where you are
connecting. The MAC address cannot be the broadcast address "ff:ff:ff:ff:ff:ff."
Click Save to save your port changes.
McAfee Network Security Platform 8.1
IPS Administration Guide
103
4
Configuring the monitoring and response ports of a Sensor
View management port settings
View management port settings
You can view the details of the management port settings.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | Setup | Physical Ports.
2
Click on the Management Port tab. The following information is displayed.
Settings
Description
IPv4
IP Address
Displays the IPv4 IP address.
Network Mask
Displays the Network mask for IPv4
Default Gateway
Displays the Default Gateway for Ipv4
IPv6
IP Address
Displays the IPv6 IP address.
Network Mask
Displays the Network mask for IPv6
Default Gateway
Displays the Default Gateway for Ipv6
Physical
Speed(duplex)
Specifies the speed and duplex of the management port
You will not be able to modify any settings in this page. The settings can be modified only from the
device CLI.
104
McAfee Network Security Platform 8.1
IPS Administration Guide
5
Deployment of Sensors in inline mode
Inline monitoring mode provides prevention of attacks by enabling Security Administrators to select
the types of attacks/traffic to drop, thus preventing the negative end-system impact common with
today's network attacks. Inline mode is achieved when the Sensor is placed directly in the path of a
network segment, becoming, essentially, a "bump in the wire," with packets flowing through Sensor.
In this mode, the Sensor inspects all traffic at wire-speed and can prevent network attacks by
dropping malicious traffic in real time—the Sensor actually ends the attacking transmission before it
can reach and impact the target. Preventative actions can operate at a highly granular level, including
the automated dropping of DoS traffic intended for a specific host.
When operating in inline mode, network segments are connected to two wire-matched Sensor ports
(For example, peer ports 1A and 1B), and packets are examined in real time as they pass through the
Sensor. In this mode, a packet comes in through the first interface of the pair of the Sensor and out
the second interface of the pair. The packet is sent to the second interface of the pair unless that
packet is being denied or modified by a signature.
As of release 2.1.7, Sensor ports are configured by default for monitoring in inline mode; that is,
connected inline on a network segment (For example, between a switch and a router or two switches).
A Sensor with 2.1.7 or later software will initially come online with its peer ports configured in pairs
and in inline mode.
This change will not override user-configured settings. Deployed Sensors upgraded to 2.1.7 or later and
will retain their user-configured settings.
Contents
Benefits of running inline mode
Inline deployment walkthrough
Determine your high availability strategy
Setting up the Sensor
Failover — Configuration of two Sensors in inline mode
McAfee Network Security Platform 8.1
IPS Administration Guide
105
5
Deployment of Sensors in inline mode
Benefits of running inline mode
Benefits of running inline mode
The benefits to using Sensors in inline mode are:
•
Protection/Prevention — Prevention is a feature unique to inline mode. When running inline, a
Sensor can drop malicious packets and not pass them through the network. This acts sort of like an
"adaptive firewall," with your detection policy dictating what is dropped. Furthermore, when
dropping packets, Network Security Platform is very precise and granular. The Sensor can drop only
those packets it identifies as malicious or all of the packets related to that flow (a choice that is
user configurable).
•
Packet "scrubbing" — In addition to dropping malicious traffic, Network Security Platform can
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 — Sensors are able to process packets at wire rates.
In inline mode, the Sensor logically acts as a transparent repeater with minimal latency for packet
processing. Unlike bridges, routers, or switches, the Sensor does not need to learn MAC addresses
or keep an ARP cache or a routing table.
Inline deployment walkthrough
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.
Task
1
Determine the optimal high availability strategy for the Sensor.
This indicates how you would like the Sensor to behave when it fails (that is, fail-open, fail-closed,
or support a failover/high-availability configuration).
2
Physically install the Sensor on your network, and connect the Sensor cables for the deployment
mode of your choice.
For example, connect one Sensor standalone (to fail-open, if applicable, or configure two Sensors
as part of a failover pair).
3
Configure the Sensor monitoring ports.
4
Configure one or more policies for the inline ports.
5
Understand how blocking works, and configure blocking.
You must use Manager to configure most aspects of your Sensor(s), including port configuration,
pairing two Sensors for failover operation, and configuring and applying policies to detect and drop
malicious traffic.
106
McAfee Network Security Platform 8.1
IPS Administration Guide
Deployment of Sensors in inline mode
Determine your high availability strategy
5
Determine your high availability strategy
Before you move your Sensor inline, consider the impact of a Sensor outage and its effect on your
network. In inline mode, the Sensor does become a single point of failure. Network Security Platform
provides a variety of options to minimize network downtime in the event of Sensor failure. For
example, Sensors support complete stateful failover, delivering the industry's first true high-availability
IPS deployment, similar to what you'd find with firewalls. If you're running the Sensor in inline mode,
McAfee recommends that you deploy two Sensors redundantly for failover protection.
Failover or high availability
Where redundancy is an essential requirement, it is best practice to implement Network Security
Platform 'high-availability' configuration. When running Sensors inline, this option is available to an
identical pair of Sensors (same model, software image, signature set) deployed redundantly in inline
mode. Both Sensors in the pair are active and share full state, so that the information on both Sensors
is always current. Latency is very minimal; than other devices providing failover, such as, firewalls.
The keys to the Network Security Platform failover architecture are as follows:
•
Sensors configured for failover confirm a heartbeat once each second.
•
Sensors configured for failover share flow information in real time.
•
Sensors are invisible at Layer 2 and above; the monitoring ports do not have MAC addresses.
As a result, you do not have to worry about Layer 2 and 3 topology changes when you introduce
Network Security Platform failover into the environment, and in the unlikely event of a Sensor failure,
failover is instantaneous and connection state is maintained.
All Sensor models support failover.
See also
Failover — Configuration of two Sensors in inline mode on page 112
Fail-open or fail-closed functionality
Sensor ports deployed in inline mode have the option of failing open or closed. Similar in terminology
to firewall operation, ports failing open allow traffic to continue to flow. Thus, even if the ports fail,
your Sensor does not become a bottleneck. However, monitoring ceases, allowing all traffic to continue
to flow through the network, which can allow attacks to impact systems in your network. When ports
are configured to fail-closed, the Sensor does not allow traffic to continue to flow, thus the failed ports
become a bottleneck, stopping all traffic at the Sensor.
There are security consequences when the Sensor is in bypass mode. When bypass mode is on, the
traffic bypasses the Sensor and is not inspected; therefore, the Sensor cannot prevent malicious
attacks.
There are two fail-open options available:
Fail-open with external hardware
Inline fail-open mode, available for both 10/100 and GE links, guarantees that data will be forwarded
over a monitored link in the event that the Sensor's processes are temporarily stopped for upgrades or
when the Sensor fails. This guarantee is delivered for 10/100 port pairs using an internal mechanical
McAfee Network Security Platform 8.1
IPS Administration Guide
107
5
Deployment of Sensors in inline mode
Setting up the Sensor
tap that connects the monitoring ports when hardware failure is detected. The 10/100 configurations
is a choice made per port pair. The Gigabit fail-open implementation involves the use of the external
Gigabit Fail-Open Kit, which includes a Bypass Switch.
Note that Sensor outage breaks the link connecting the devices on either side of the Sensor and
requires the renegotiation of the network link between the two peer devices connected to the Sensor.
Depending on the network equipment, this disruption introduced by the renegotiation of the link layer
between the two peer devices may range from a couple of seconds to more than a minute with certain
vendors' devices.
A very brief link disruption may also occur while the links between the Sensor and each of the peer
devices are renegotiated to place the Sensor back in inline mode. This outage, again, varies depending
on the device, and can range from a few seconds to more than a minute.
Fail-open with the layer 2 passthru (L2) feature
Layer 2 Passthru is also known as software fail-open. The L2 feature, when triggered, causes traffic to
flow through the Sensor without being copied to the detection engine.
The Layer 2 Passthru option is provided specifically to handle internal Sensor errors; it is not provided
as an alternative to other HA options, such as the Fail-Open kit.
Setting up the Sensor
Each Sensor model is shipped with documentation on how to set up the Sensor and configure it to
communicate with the Manager. This documentation consists of model-specific product guides and
quick start guides. These documents provide detailed installation, configuration and cabling
instructions for your Sensor.
You may need special equipment depending on your deployment strategy. Certain Sensor models have
Fast Ethernet (FE) ports. Each FE port requires a Network Security Platform dongles for In-line
Fail-closed mode. Dongles are included with FE-port Sensors. Gigabit Ethernet (GE) port Sensors
require the optional Gigabit fail-open bypass kit (Optical Single-mode, Optical Multimode, or Copper),
sold separately, for in-line fail-open mode.
The following table shows the monitoring port types for each Sensor model.
I-series Sensor Monitoring port type Fail-open behavior
108
I-4010
GE ports
Fail-closed; require external fail-open kit
I-4000
GE ports
Fail-closed; require external fail-open kit
I-3000
GE ports
Fail-closed; require external fail-open kit
I-2700
FE ports GE ports
Fail-open; require no extra hardware Fail-closed; require
external fail-open kit
I-1400
FE ports
Fail-open; require no extra hardware
I-1200
FE ports
Fail-open; require no extra hardware
M-series Sensor
Monitoring port type
Fail-open behavior
M-8000
GE ports
Fail-closed; require external fail-open kit
M-6050
GE ports
Fail-closed; require external fail-open kit
M-4050
GE ports
Fail-closed; require external fail-open kit
M-3050
GE ports
Fail-closed; require external fail-open kit
McAfee Network Security Platform 8.1
IPS Administration Guide
5
Deployment of Sensors in inline mode
Setting up the Sensor
M-series Sensor
Monitoring port type
Fail-open behavior
M-2750
GE ports
Fail-closed; require external fail-open kit
M-1450
GE ports
Fail-closed and fail-open built-in
M-1250
GE ports
Fail-closed and fail-open built-in
NS-series Sensor
Monitoring port type
Fail-open behavior
NS9100
GE ports
Fail-closed; require external fail-open Kit
NS9200
GE ports
Fail-closed; require external fail-open Kit
NS9300
GE ports
Fail-closed; require external fail-open Kit
How to connect the fast ethernet monitoring ports
The FE ports available on some Sensor models failopen and require no extra hardware; simply connect
your cables to a port pair (For example, 1A-1B).
Fail-closed mode for FE ports requires use of the fail-closed dongles on each connecting cable of the
port pair. The fail-closed dongles provided with the Sensor are designed to complement 10/100
monitoring port functionality. You plug the dongles into a Sensor's 10/100 monitoring port, and then
connect a Cat 5/Cat 5e cable to the dongles.
How to connect the gigabit ethernet monitoring ports
Fail-Open mode for Gigabit Ethernet (GE) ports requires use of the external Gigabit fail-open Kit. This
kit includes a Gigabit bypass switch and an adaptor that connects the switch to the Sensor.
Fail-closed mode for GE ports requires no extra hardware; simply connect your fiber cables to the GE
port pair (For example: 1A-1B).
For information on how to connect the Sensor with a Gigabit Fail-Open Kit, see the documentation that
accompanies the kit. For example, the Gigabit Copper Kit includes McAfee Network Security Platform
Gigabit Copper Fail-Open Kit Guide.
Failover pair cable connections
Failover requires connecting the paired Sensors via an interconnection cable or cables. Communication
between paired Sensors maintains the failover heartbeat and state information.
There is no standard heartbeat port across all the Sensor models. The port or ports you use to connect
the two Sensors depends on the Sensor model. The Sensor models and their failover interconnection
ports are described below.
I-series Sensor
Failover port
I-4010
HA1 and HA2 (6A and 6B)
I-4000
2A and 2B
I-3000
HA1 and HA2 (6A and 6B)
I-2700
4A
I-1400
Response port 1 (R1)
I-1200
Response port 1 (R1)
McAfee Network Security Platform 8.1
IPS Administration Guide
109
5
Deployment of Sensors in inline mode
Setting up the Sensor
M-series Sensor
Failover port
M-8000
HA1 and HA2 (3A and 3B)
M-6050
HA1 (4A). Note that HA2 (4B) remains unused
M-4050
2A
M-3050
2A
M-2750
10A
M-1450
4A
M-1250
4A
NS-series Sensor
Failover port
NS9100
G0/1
NS9200
G0/1
NS9300
G1/1 and G1/2
The following is a quick summary of the rules for connecting cables:
•
Connecting the heartbeat cable must be direct; you must not connect the heartbeat cable through
another network device, such as a switch.
•
When 2 ports are used on each Sensor for the heartbeat connection, always connect cables
between identical port names. For example, port 2A on Sensor 1 must be connected to port 2A on
Sensor 2 (not 2B).
How to configure the Sensor monitoring ports
After you have installed and connected the Sensor(s), you must configure the Sensor's ports. The
following list summarizes the port configuration requirements:
•
The port configuration must match the Sensor cable connections: for example, if you connect the
port with no fail-open Kit, the port must be configured as in-line, fail-closed, and not fail-open.
•
The ports must be set to in-line, and to fail-open or fail-closed as appropriate
•
The ports must be enabled.
About Sensor port configuration
Before you configure the Sensor ports, you must have installed the Sensor and added to the Manager
interface.
Configure inline mode for a single Sensor
This section contains recommendations for deploying a single Sensor in inline mode.
Configuration for a fail-open kit is described in the fail-open kit documentation. For example, to
configure the Sensor to work with the copper fail-open kit, see the McAfee Network Security Platform
Gigabit Copper Fail-Open Bypass Kit Guide.
110
McAfee Network Security Platform 8.1
IPS Administration Guide
Deployment of Sensors in inline mode
Setting up the Sensor
5
Task
1
In the Manager interface, select My Company | Device List | <Device_Name> | Setup | Physical Ports.
2
Click a numbered port (for example, 2B) from Monitoring Ports.
Monitoring Port Details window displays current port settings.
Figure 5-1 Verifying ports for in-line fail-open mode
3
Set the Administrative State to Disable (off).
4
Select the Port Speed.
5
Do one of the following:
•
For inline fail-closed operation, select In-line Fail-closed as the Operating Mode.
•
For inline fail-open operation, select In-line Fail-open as the Operating Mode. Confirm (Yes) that you
have already connected the bypass switch and controller or control cable.
6
Select the area of your network to which the current port is connected: Inside (traffic initiating
internally, destined for the external network) or Outside (traffic initiating externally, destined for the
internal network).
7
Set the Administrative State to Enable (on).
8
Click Save.
9
Repeat for any other ports you need to configure.
10 Download the changes to your Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
111
5
Deployment of Sensors in inline mode
Failover — Configuration of two Sensors in inline mode
Failover — Configuration of two Sensors in inline mode
In a failover configuration, the two Sensors are placed inline, connected to each other via cables, and
configured to act as a 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.
When deploying the two Sensors in failover mode, you must ensure the following:
•
The Sensor interconnection ports must be connected appropriately so the two Sensors can
communicate.
•
Both Sensors must be of the identical model type, and have the same signature set and software
loaded. (One of the two Sensors may be a "Failover (FO)" Sensor model, which is a fully functional
Sensor limited to operation as part of a failover pair; it cannot operate standalone.)
•
Additionally, all ports on both the Sensors must be configured to run in inline mode.
The exceptions are the ports that will be used for the heartbeat. For example, on the I-2700, you do not
need to explicitly configure ports 4A/4B to run in inline mode because 4A will be automatically
configured for the heartbeat and 4B will be disabled when the failover pair is created.
Creating a failover pair
You can create a failover pair using Manager's System Configuration Tools page. Failover pair creation
happens in real time; there is no need to explicitly update the configuration.
By design, the configuration of the primary Sensor is copied to the secondary Sensor, overwriting the
original configuration on the secondary. If you intend to configure both Sensors to fail-closed or
fail-open, you need only configure the ports on the Sensor you intend to designate as the primary
during the failover pair creation.
If you intend to have one Sensor fail-closed and the other fail open, however, you must revisit the Port
Configuration page of each Sensor after failover pair creation and make the appropriate changes.
Task
1
Select My Company | Device List | Failover Pairs.
2
Click New.
The Add a Failover Pair dialog opens.
3
Select the Sensor Model type.
Both Sensors in a failover pair must be the same model.
112
4
Type a failover pair Name that will uniquely identifies the grouping.
5
Select the Primary Sensor Template Device from the drop-down menu.
6
Select the Secondary Sensor Peer Devicefrom the drop-down menu.
McAfee Network Security Platform 8.1
IPS Administration Guide
Deployment of Sensors in inline mode
Failover — Configuration of two Sensors in inline mode
7
Click Create. Upon saving, a message informs you that the failover pair creation will take a few
moments.
8
Click OK. The new failover pair appears as a child node of the Sensor node under which it was
created.
5
That node contains icons for each interface taking part in the failover process. Also within the
failover pair node is a list of its member Sensor.
Most configuration options are hereafter done at the failover pair node level. For example, you can
now apply a policy or update the configuration at the failover pair node level and it will
automatically propagate to each of the member Sensors. On the other hand, you still configure the
port settings, view interface statistics, and upgrade the Sensor software at the Sensor node level.
The easiest way to get a feel for the failover pair configuration process is to examine the user
interface once the pair has been created.
The Sensors must be running the same software version to run in a failover configuration. However,
you upgrade software at a Sensor level, even those that are part of a failover pair. The
recommended upgrade procedure is to therefore upgrade the software version on both Sensors, and
then restart them sequentially. That is, once the upgrade process is complete on both, restart (for
example) the secondary, confirm that it has restarted without error, and restart the primary.
Download configuration, signature set, and software updates to the Sensor
After configuring your ports for inline mode, setting the TCP/IP parameters, and customizing and
applying policy, you will need to download this configuration to the Sensor in order for all of your
changes to be active.
•
Configuration changes, including port configuration, policy, and signature set updates: My Company |
Device List | <Device_Name> | Physical Device | Configuration Update
•
Software updates only: My Company | Device List | <Device_Name> | Physical Device | Software Upgrade
See also
Deploy pending changes to a device on page 317
McAfee Network Security Platform 8.1
IPS Administration Guide
113
5
Deployment of Sensors in inline mode
Failover — Configuration of two Sensors in inline mode
114
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high
availability
Most networks today have some amount of in-built redundancy. However, the extent to which a
network can withstand a failure varies, depending on the environment. For example, one setup might
have two fully redundant paths to and from the Internet, whereas another might have Primary and
Secondary firewalls, but single points of failure elsewhere.
Network devices traditionally provide redundancy at Layer 2 or 3 of the OSI model. That is, they take
advantage of the existing switching or routing infrastructure to provide fault tolerance.
The principle behind hot standby router protocol (HSRP - RFC 2281) and virtual router redundancy
protocol (VRRP - RFC 2338), for example, is that two or more routers share a virtual IP (VIP) address.
One router takes on a primary role and "owns" the VIP; all traffic directed to the VIP routes through
the primary when all is well. If the primary goes offline, a standby router is automatically promoted
and takes over ownership.
Because most network devices run at Layer 2 or higher, incorporating redundancy often requires a
logical topology change. As a simple example, to add the aforementioned router redundancy, you have
to reconfigure all downstream routers to use with the new VIP as their default gateway.
Contents
Network Security Platform fail-over architecture
Sensor fail-over implementation
How to understand the current network topology
Optimal Sensor location determination
Configuration of the ports on each Sensor
How dongles work
Installation of the Sensors physically
How to define the Network Security Platform fail-over pair
Connecting heartbeat cables
Verification of the fail-over configuration
Network scenarios for Sensor high availability
Network Security Platform fail-over architecture
Network Security Platform was built with high availability in mind. In fact, those who initially become
confused by the possibilities around Network Security Platform fail-over usually do so because the
implementation is actually simpler than they assume initially.
McAfee Network Security Platform 8.1
IPS Administration Guide
115
6
How to configure Sensors for high availability
Sensor fail-over implementation
Note the following points regarding Network Security Platform fail-over architecture:
•
Sensors are invisible at layer 2 and above; the monitoring ports do not even have MAC addresses.
•
Sensors configured for failover confirm a "heartbeat" once each second.
•
Sensors configured for fail-over share flow information in real time.
As a result, you do not have to worry about Layer 2 and 3 topology changes when you introduce
Network Security Platform fail-over into the environment; and in the unlikely event of a Sensor failure,
fail-over is instantaneous and connection state is maintained.
Sensor fail-over implementation
A typical Network Security Platform failover implementation includes the following steps:
•
Understanding the current network topology
•
Determining optimal Sensor location
•
Configuring the ports on each Sensor
•
Physically installing the Sensors
•
Defining McAfee Network Security Platform failover Pair
•
Connecting the heartbeat cables
•
Verifying the failover configuration
In the sections that follow, we will consider each of these points in detail.
How to understand the current network topology
Understanding the current network topology is essential for the proper planning of Network Security
Platform fail-over solution. Rather, the more you understand about the existing data flow, the less
likely you run into obstacles during implementation.
The most common network topologies can be summarized as follows:
•
Two paths - Active/Passive
•
Two paths - Active/Active
•
A single path
Two paths - Active/passive
Most redundant links today are made up of active or passive paths. There are two ways in and out of
the network, but only one way will actually be available at any given time. The path passing traffic is
called the active path, and the one standing by in the event of a failure is called the passive path.
HSRP, VRRP, spanning tree protocol (STP), and Dynamic Routing Protocols, such as, OSPF, EIGRP, and
BGP, are arguably the most common technologies used to automate network failover. Admittedly,
many of these include options to balance traffic, but they are historically configured to allow for one
path to pass traffic at a time.
116
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Optimal Sensor location determination
Two paths - Active/active
Some networks will maintain two active paths to and from the Internet. In addition to redundancy,
these approaches can potentially double the available bandwidth, under normal conditions.
In most cases, the two paths are not designed to share traffic unless there is a failure. When all is
well, a flow will be established on one of the paths, and all packets from that flow will traverse the
same path.
In some cases, however, the network infrastructure is designed in such a way that cross both paths
under normal circumstances. For example, inbound requests might come in on path A and outbound
responses might go out on path B. Such traffic is said to be asymmetrically routed.
Of course, if one path becomes unavailable, all traffic will be routed across the remaining path.
A single path
Some networks do not include much or any redundancy. In this case, there is one or more single
points of failure.
If one of the non-redundant devices fails, the connection to the Internet will fail as well.
Most companies that choose to invest in a redundant Network Security Platform solution also invest in
redundant paths to and from their network. That is, there are numerous companies that have single
points of failure, but insist on implementing Network Security Platform failover.
Optimal Sensor location determination
The previous section is mostly intended as a point of reference. The good news is that Network
Security Platform fail-over process is often identical, whether the network fail-over configuration is
active-active, with or without asymmetric routing, active-passive, or even made up of a single path.
The details are as follows:
•
Both the Sensors in a fail-over pair are always in an active state. In this way, they are sure to
protect a network on which the redundant path is active.
•
However, such an approach does not preclude the Sensors from protecting a network on which the
Secondary path is passive; the Sensor on the passive path will not have much or any flow
information to pass to its counterpart.
•
Sensors in a fail-over Pair scan independently, but use the information they share with each other
during the scanning process. In this way, if a flow happens to be asymmetrically routed across both
Sensors, each Sensor will end up with the full flow.
Redundant Sensors on redundant paths
Determining the optimal physical location for the Sensors on a redundant network is usually quite
obvious. If you ignore the idea of McAfee Network Security Platform fail-over for a moment, the rule of
thumb for Sensor placement is to install the Sensor along the same boundaries of trust that often
guide firewall placement. In fact, most Sensor installations are either directly inside or directly outside
the company firewall. Of course, like a firewall, a Sensor can be used deep inside an enterprise to
isolate one segment of the network from the next.
McAfee Network Security Platform 8.1
IPS Administration Guide
117
6
How to configure Sensors for high availability
Optimal Sensor location determination
The same basic rule applies to Network Security Platform fail-over. If the network currently has
parallel firewalls connected to parallel switches, for example, it follows that you can introduce parallel
Sensors between them. The following set of diagrams is a very simple "before and after," to help
clarify the logic. (The dotted line represents a heartbeat link.):
Figure 6-1 Determination of optimal Sensor location — Before
Figure 6-2 Determination of optimal Sensor location — After
118
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Optimal Sensor location determination
The key is to ensure the redundant Sensors will be scanning the same traffic at the same point in the
network. If you were to instead place one Sensor outside the firewall on one path and the other
Sensor inside the firewall on the other path, the outcome is what developers like to refer to as
"undefined." That is, there is no telling what false positives and false negatives, and even instability,
such a setup might produce.
Redundant Sensors on a single path
Sensor failover is typically straightforward to implement in the more complicated environments
because Network Security Platform was engineered to seamless slip onto networks with existing,
redundant paths. The irony is that introducing a Sensor failover Pair onto a network with a single path
often requires some additional thought:
A pair of Sensors can run in parallel on a network that otherwise has no or little redundancy. For
example, you might "sandwich" a pair of Sensors between a pair of switches and use STP to control
the failover process. The drawback to relying on STP, however, is that you inherently complicate the
Layer 2 infrastructure and STP convergence typically takes between 12 and 50 seconds; so it's not
ideal.
Instead, consider the configuration in the below figure for a single path:
Figure 6-3 Stack configuration
In this scenario, the Sensors are "stacked" (one after the other) in much the same way you might
daisy chain a pair of switches.
A crossover cable is required to make the connection between the Sensor monitoring ports.
These Sensors are configured to run inline, failopen, and function as a failover Pair.
McAfee Network Security Platform 8.1
IPS Administration Guide
119
6
How to configure Sensors for high availability
Configuration of the ports on each Sensor
The advantages of this redundant configuration over others on a network with a single path are as
follows:
•
There is no dependency on the Layer 2 or Layer 3 topologies for Sensor redundancy.
•
If one Sensor fails, it fails open, and the other Sensor continues to scan with no interruption.
•
Because they are configured as a failover Pair, state will be maintained.
The single disadvantage is that duplicate alerts will be generated for UDP and ICMP attacks.
How to prevent duplicate alerts
To prevent the failover pair from forwarding the same alert twice, each node in the pair adheres to the
following rules:
•
The Sensor that received the attack packet on its monitoring port sends the signature alert to the
Manager. (The Sensor that gets a copy of the attack packet from its failover peer does not send an
alert.)
•
The Sensor forwarding the alert also takes the configured response action, such as sending a TCP
reset.
•
The Sensor that has been online the longest is responsible for sending all reconnaissance and DoS
alerts to the Manager.
•
In the event that both Sensors have been up for exactly the same amount time, the Sensor with
the higher value serial number will be responsible for sending all reconnaissance and DoS alerts.
The reality check is that because the previous "stacked" configuration results in attacks arriving on the
monitoring ports of both Sensors (unless blocking is enabled), this configuration will cause some
duplicate alerts to be generated. The details are as follows:
•
There will be no issue with reconnaissance and DoS attacks because one Sensor in a failover Pair is
always dedicated to send these alerts.
•
There will be no issue with TCP signature attacks either, thanks to the stateful nature of the
scanning engine. That is, even though both Sensors will get the attack packet on their monitoring
ports, the second Sensor will actually get the packet on its failover port first. When it subsequently
gets the packet for a second time on its monitoring port, the packet will be recognized and treated
as a duplicate packet. The duplicate packet will be forwarded along, but no alert will be generated.
•
However, because UDP and ICMP are not stateful, the same logic does not apply to those packets.
Instead, UDP and ICMP attacks will create duplicate alerts in this configuration.
Summary
If the current network failover topology has been configured in a logical fashion, you will no doubt see
a pattern as you research the existing infrastructure. In this case, follow that pattern when you add
the Sensors. If the current topology does not follow a logical pattern, address the issue before you
consider adding Network Security Platform failover, and avoid the possibility of Network Security
Platform taking the blame for a flaw in the network design.
Configuration of the ports on each Sensor
To function as a failover Pair, the two McAfee® Sensors must be the same model and have the same
Sensor image (Sensor software version).
120
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Configuration of the ports on each Sensor
Previously, you could create Sensor fail-over pair only if all the monitoring ports of the primary sensor
were in Inline mode. Now, you can create Sensor fail-over pairs even if the monitoring ports are in
different operating modes, that is some ports in Inline, some in SPAN, and some in Tap mode. For
example, you can create an I-4010 fail-over pair with monitoring ports 1A-1B, 2A-2B, 3A-3B and
4A-4B deployed in Inline mode and port 5A deployed in SPAN mode.
In some Sensor models, a monitoring port is configured for the primary-secondary heartbeat. In such
cases, the peer monitoring port is disabled. For example, in I-2700, monitoring port 4A is used for the
heartbeat and when you create the failover pair, port 4B is disabled.
Note that the port deployment modes of both the primary and secondary Sensors must be the same.
For example, if port 5A is deployed in SPAN mode in the primary then 5A of the secondary must be
deployed in SPAN mode as well.
By design, there will always be a certain amount of independence among the Sensors. For example,
the solution must be flexible enough to handle a network on which a primary path runs at 100 Mbps
full duplex, but the secondary path runs at only 10 Mbps half duplex.
This is the proper time to configure each port pair to fail open or closed. In previous Network Security
Platform versions, you could only configure each Sensor in a failover Pair to fail closed. Now, you can
configure one Sensor to fail closed and the second to fail open.
There is no special requirement for a minimum Sensor software version to be able to configure one
Sensor to fail closed and the other to fail open.
You can configure both the port speed and operating mode from the Configure Ports page of the user
interface:
Figure 6-4 Configure Monitoring port: 1A window
McAfee Network Security Platform 8.1
IPS Administration Guide
121
6
How to configure Sensors for high availability
Configuration of the ports on each Sensor
If you choose to fail closed on an Ethernet port pair (not GBICs), the user interface will remind you to
cable the ports with the Network Security Platform dongles.
Network Security Platform dongles ship with the Sensors.
Potential pitfall
When you configure a failover Pair, you must designate a "Primary" and "Secondary" Sensor. By
design, the configuration of the Primary Sensor is copied to the Secondary Sensor, overwriting the
original configuration on the Secondary.
If you intend to configure both Sensors to fail closed or fail open, you configure the ports on the
Sensor you intend to designate as the primary during the failover Pair creation process.
If you intend to have one Sensor fail closed and the other fail open, however, you must revisit the Port
Configuration page of one or both Sensors after the failover Pair creation and make the appropriate
changes.
A note on fail open functionality for GE ports
Unlike the Fast Ethernet ports, the GE ports cannot fail open on their own. You must purchase an
optical bypass kit for each port pair you wish to fail open.
If a Sensor is restarted, hangs, or fails to come up after being turned on, the optical bypass kit takes
over and ensures the link remains active. When configured as a failover Pair, this logic still applies,
except in the case in which the Sensor port actually fails. In this case, the bypass kit does not change
to bypass mode. Instead, the port pair fails closed and the redundant link takes over.
The details of optical bypass kits are currently beyond the scope of this document. Refer to McAfee
Network Security Platform Gigabit Optical Fail-Open Bypass Kit Guide, which accompanies the Optical
Fail-Open kit).
A caution about active-passive failover
The option to fail one Sensor closed and one Sensor open was intended for use with active-passive
configurations. When the order in which the redundant paths will be used is known, you can safely
configure the Sensor on the primary path to fail closed and the Sensor on the secondary path to fail
open. The result is as follows:
•
If the Sensor on the primary path fails, it will force the secondary path to take over, which will
ensure the link remains protected.
•
In the unlikely event that the secondary path has become active and the Sensor on it fails as well,
traffic will no longer be scanned, but will continue to flow.
You might prefer to shut down the Internet connection if the traffic on the secondary path cannot be
scanned for intrusions. In this case, you would configure both Sensors to fail closed.
On a network on which both paths are active, there is no way to predict the order in which the paths
will fail. Configuring a Sensor to fail open in this context would at best negate the purpose of the
Network Security Platform redundancy. Furthermore, if there were asymmetric flows on the paths, the
remaining Sensor would not see all the packets from those flows and therefore be susceptible to false
positives and false negatives.
122
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
How dongles work
How dongles work
Dongles, included with all 10/100-port Sensors, are required when a 10/100 Sensor port runs in SPAN
or inline fail-closed mode.
All 10/100 ports on the Sensors are standard 10/100 Base-T Ethernet ports. As such, they make use
of only 4 of the 8 wires in a category 5/6 twisted pair cable:
Pin
Function
1
Tx
2
Tx
3
Rx
4
5
6
Rx
7
8
Pins 1 and 2 are used to transmit (Tx) signals, pins 3 and 6 are used to receive (Rx) signals, and pins
4, 5, 7, and 8 are not used.
When a port pair operates in inline fail-open mode, the signals are "crossed" to allow for the normal
flow of traffic.
In this way, traffic that is received on the Rx pins on one port are sent on the Tx pins on the other
port.
This is the same cross performed by a crossover cable.
McAfee Network Security Platform 8.1
IPS Administration Guide
123
6
How to configure Sensors for high availability
How dongles work
A group of mechanical relays actually resides between each port pair:
Figure 6-5 Mechanical relays
Figure 6-6 Mechanical relay
The relays come into play when the Sensor is shut down. Specifically, the relays provide a path for the
signals on pins 1, 2, 3, and 6 to continue to pass when the Sensor is turned off. In short, the relays
ensure that the Sensor will fail open.
It is important to note that the relays provide a path for the signals on pins 1, 2, 3, and 6 only. The
signals on pins 4, 5, 7, and 8 are instead filtered out.
When the Sensor runs in inline fail-closed mode, the Sensor uses pins 4 and 5 instead of pins 1 and 2
to transmit signals:
Figure 6-7 Tx signals on pins 4 and 5
124
McAfee Network Security Platform 8.1
IPS Administration Guide
How to configure Sensors for high availability
How dongles work
6
Again, the relays come into play when the Sensor is turned off:
Figure 6-8 Mechanical relay — Fail-closed
Because the relays only pass the signals on pins 1, 2, 3, and 6, however, the transmit signals on pins
4 and 5 are filtered out and the ports fail closed.
So what does the dongle do? The answer becomes obvious when we compare the Sensor port pin-outs
configured for fail-closed operation to standard Ethernet cable pin-outs:
Figure 6-9 Pin-out comparison
As the previous diagram indicates, a Sensor in fail-closed mode uses pins 4 and 5 to transmit signals,
yet standard 10/100 Ethernet connections use pins 1 and 2 to transmit signals (pins 4 and 5 are not
used). Without a mechanism to transpose the signals, traffic therefore comes to a halt.
The operating mode of the Sensor has no effect on the receive (Rx) signals, so they are not shown here
for simplicity.
McAfee Network Security Platform 8.1
IPS Administration Guide
125
6
How to configure Sensors for high availability
Installation of the Sensors physically
The sole purpose of the dongles is to transpose the transmit signals from pins 4 and 5 (back) to pins 1
and 2 so the Sensor can communicate with standard Ethernet devices when turned on:
Figure 6-10 Dongle transposes signals
The inner workings of the dongle are shown in the figure below.
Figure 6-11 Inner workings of dongle
When the transmit signals go from the fail-closed port on the Sensor to the male end of the dongle,
they do so on pins 4 and 5. When they go from the female end of the dongles to a standard 10/100
Base-T cable, however, they use pins 1 and 2, which is the Ethernet standard.
The same approach is used to prevent loops from a Sensor port operating in SPAN mode. Imagine that
ports 2A and 2B are each running in SPAN mode. When the Sensor is turned on, because each port is
configured for SPAN mode, the Sensor software will prevent traffic from passing between the pair. But
when the Sensor is turned off, the relays will, by design, allow transmit signals to pass over pins 1 and
2. To avoid this situation, which will only serve to confuse the remote devices (and even possibly
create bridging loops), Sensor ports configured for SPAN mode also transmit on pins 4 and 5 and
therefore require the dongles.
Installation of the Sensors physically
Installing Sensors at this point may seem premature. After all, you will no doubt perform tests once
the failover pair has been configured. The logic here is to confirm connectivity and proper scanning
with as few variables as possible. If basic connectivity and scanning prove to be fine now, but fail after
configuring the failover pair, you at least know the issue is specific to the failover pair.
126
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Installation of the Sensors physically
During Sensor boot up, there is a small time difference between when an inline fail-open port pair is
enabled (port status LED is green) and actually put inline (activity LED starts blinking). This causes a
minor traffic loss. Such a time difference does not exist in the M-series Sensors.
Ideally, you should test each Sensor individually. This includes, if need be, manually failing over the
Primary path, so traffic will flow across the Secondary path.
You can use common utilities like Ping and Traceroute (tracert.exe on Windows) to test basic connectivity.
You can also look at the statistics from the Threat Analyzer for each Sensor port to confirm that traffic
is properly flowing through it.
Figure 6-12 Sensor performance option
For step-by-step procedures on verifying how to verify traffic is flowing through the Sensor, see the
McAfee Network Security Platform Manager Administration Guide.
An easy and benign way to confirm that Network Security Platform is scanning for exploits is to trigger
a FTP directory traversal signature.
McAfee Network Security Platform 8.1
IPS Administration Guide
127
6
How to configure Sensors for high availability
Installation of the Sensors physically
The "attack" looks as follows:
Figure 6-13 FTP traversal attack
The highlighted section is the command that actually trips the signature.
The corresponding attack will look similar to the alert in Figure
Figure 6-14 Show details of specific attack
If you are interested in HTTP tests, you can instead try the following URLs from your favorite browser:
http://serveraddress/inetpub/scripts/root.exe
128
McAfee Network Security Platform 8.1
IPS Administration Guide
How to configure Sensors for high availability
How to define the Network Security Platform fail-over pair
6
http://serveraddress/inetpub/scripts/cmd.exe
These exploits are specific to IIS.
These URLs are synonymous with Code Red and Nimda exploits, so they may trigger anti-virus software
on the Web server as well.
Use these tools forNetwork Security Platformtesting purposes only. McAfee in no way condones use
of attack traffic for any reason other than testing product connectivity and communication.
Reality check — Asymmetric routing
In the case in which the network has two active paths that route asymmetrically, these initial intrusion
tests might not be successful and you may even see false positives.
In such a case, you can instead temporarily assign the All inclusive with audit policy to the interface(s)
at hand to help confirm the scanning process, or skip testing for now and hope all goes well in the
steps to follow.
How to define the Network Security Platform fail-over pair
After the Sensors are known to be working independently, we are ready to define a fail-over Pair. It is
by way of the fail-over Pair configuration that we ensure the Sensors share flow information under
normal conditions and also fail over as required.
In Figure, we have specified the Sensor model in question (I-4010), named the fail-over pair,
FO-pair-4010, and selected the two intended Sensors:
Again, the one important consideration is that the current configuration of "primary" Sensor will be
copied over that of the "secondary" Sensor during the pair creation process.
The creation of a fail-over pair happens in real time. There is no need to explicitly update the
configuration.
When it comes to scanning roles, however, you can safely ignore the terms Primary Sensor and
Secondary Sensor here. Remember that both Sensors are always scanning actively.
After completion, the display of the user interface will change to reflect the existence of the new
fail-over pair:
A new fail-over pair node now exists in the resource tree (left pane) in Figure. That node contains
icons for each interface taking part in the fail-over process. Also within the fail-over pair node is a list
of its member Sensors.
Most configuration options are hereafter done at the fail-over pair node level. For example, you can
now apply a policy or update the configuration at the fail-over pair node level and it will automatically
propagate to each of the member Sensors. On the other hand, you still configure the port settings,
view interface statistics, and upgrade the Sensor software at the Sensor node level. So the easiest
way to get a feel for the fail-over pair configuration process is to examine the user interface once the
pair has been created.
The Sensors must be running the same software version to run in a fail-over configuration. However,
you upgrade software at a Sensor level, even those that are part of a fail-over pair. The recommended
upgrade procedure is to therefore upgrade the software version on both Sensors, and then restart them
sequentially. That is, once the upgrade process is complete on both, restart the first, confirm that it has
restarted without error, and restart the second.
McAfee Network Security Platform 8.1
IPS Administration Guide
129
6
How to configure Sensors for high availability
Connecting heartbeat cables
It is very easy to see the details of the port status across all Sensors from the View Details page at the
Sensors level:
Figure 6-15 Sensor status and operational details
For additional details, you can dive down on the current fail-over status for a given interface from the
View Details page of that interface.
Connecting heartbeat cables
There is no standard heartbeat port across all Sensor models. Instead, the port or ports you use to
connect the two Sensors for failover depends directly on the model at hand. The details are as follows:
130
I-series Sensor model
Port(s) used for heartbeat connection
I-4010
6A and 6B (HA1 and HA2)
I-4000
2A and 2B
I-3000
6A and 6B (HA1 and HA2)
I-2700
4A
I-1400
R1 (response port)
I-1200
R1 (response port)
M-series Sensor model
Port(s) used for heartbeat connection
M-8000
3A and 3B (HA1 and HA2)
M-6050
4A (HA1—note that port 4B remains unused)
M-4050
2A
M-3050
2A
M-2750
10A
M-1450
4A
M-1250
4A
NS-series Sensor model
Port used for heartbeat connection
NS9100
G0/1
NS9200
G0/1
NS9300
G1/1 and G1/2
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Connecting heartbeat cables
Initial hints
Consider these hints when connecting cables:
•
The I-3000, I-4000, I-4010, models require two ports to share flow information at a high
throughput level.
•
Only port 4A is actually used for the heartbeat connection on the I-2700 model. Port 4B is disabled
when in failover mode.
•
Ports 6A and 6B are labeled HA1 and HA2, respectively, on the I-3000 and I-4010 models to
indicate their use in the failover process. (HA stands for High Availability.)
GBIC cable connections
All Sensor models other than the I-1200 and I-1400 use a standard GBIC, Small Form-factor
Pluggable (SFP) GBIC, or 10GbE Small Form-factor Pluggable (XFP) GBIC to make the heartbeat
connection.
Before you attempt to connect failover cables with a GBIC, complete the following steps:
1
Determine the appropriate GBIC (standard, SFP, or XFP) for the model at hand.
2
Determine the connector type required to plug the fiber optic cable into the chosen GBIC.
3
Determine the correct GBIC module type and cable to support the distance between the Sensor
pair.
If you are using copper GBICs, then use Category 6 Enhanced (Cat 6e) straight cable.
The table below addresses the first two steps. It builds off the previous table to include columns for
the port type and corresponding cable connector type:
I-series Sensor
model
Port(s) used for heartbeat connection Port type Cable connector type
I-4010
6A and 6B (HA1 and HA2)
SFP
LC
I-4000
2A and 2B
GBIC
SC
I-3000
6A and 6B (HA1 and HA2)
SFP
LC
I-2700
4A
GBIC
SC
I-1400
R1 (response port)
Ethernet
RJ45
I-1200
R1 (response port)
Ethernet
RJ45
M-series Sensor
model
Port(s) used for heartbeat
connection
Port type Cable connector type
M-8000
3A and 3B (HA1 and HA2)
XFP
LC
M-6050
4A (HA1—Note that port 4B or HA2
remains unused)
XFP
LC
M-4050
2A
XFP
LC
M-3050
2A
XFP
LC
M-2750
10A
SFP
LC
M-1450
4A
Copper
RJ45
M-1250
4A
Copper
RJ45
McAfee Network Security Platform 8.1
IPS Administration Guide
131
6
How to configure Sensors for high availability
Connecting heartbeat cables
Important notes
•
The monitoring ports and failover ports use the same GBIC. (There is no special GBIC required for
the heartbeat connection.)
•
All GBICs and fiber optic cables are sold separately from the Sensors.
McAfee only officially supports GBICs purchased from McAfee price list.
Cabling guidelines and examples
The following is a quick summary of the rules for connecting the heartbeat cables:
•
The cable connections must always cross the Tx and Rx channels between the Sensor heartbeat
ports. It is for this reason the I-1200 and I-1400 Sensors, for example, require a crossover cable
between their failover pairs.
•
When 2 ports are used on each Sensor for the heartbeat connection, you must always connect
cables between identical port names. For example, port 2A on Sensor 1 should always be
connected to port 2A on Sensor 2 (not 2B).
Some sample hardware requirements and setup hints are given in the following sections:
I-1200 and I-1400 examples
A pair of I-1200 or I-1400 Sensors located within 100 meters or less of each other would require:
•
One (1) CAT 5 crossover cable
Connect the crossover cable to each response port.
I-2700 examples
A pair of I-2700 Sensors located within 550 meters of each other would require:
•
Two (2) standard SX GBICs
•
One (1) SX fiber optic cable with SC connectors
You need 2 GBICs and a single cable because I-2700 Sensors only use port 4A for Sensor-to-Sensor
communication.
The key to a successful fiber optic connection is to make sure the cable is crossed between the
Sensors. Fiber optic cables often come with pre-set cross over configuration as shown in the following
connection example image:
Figure 6-16 Running cables
132
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Verification of the fail-over configuration
I-4000 example
A pair of I-4000 Sensors located within 10 Km of each other would require:
•
Four (4) standard LX/LH GBICs
•
Two (2) LX/LH fiber optic cables with SC connectors
The cable connection logic here is similar to the logic used with the I-2700 model. The key difference
is that the I-4000 uses ports 2A and 2B for the heartbeat connection. It follows that you take the
same approach as above, but do it twice. Specifically, you cross the cable from port 2A on the first
Sensor to port 2A on the second Sensor, and then repeat the step between port 2B on the first Sensor
and 2B on the second Sensor.
I-3000 and I-4010 examples
A pair of I-3000 or I-4010 Sensors located within 100 Km of each other would require:
•
Four (4) SFP ZX GBICs
•
Two (2) ZX fiber optic cables with LC connectors
The approach to cable connections here is the same as it is for the I-4000, except the I-3000 and
I-4010 use ports 6A and 6B (HA1 and HA2) for the heartbeat connection.
Network Security Platform has been known to work fine with ZX GBICs. However, McAfee does not sell
or actively test with ZX GBICs.
TX GBICs
McAfee also offers a TX module type for both the standard and SFP GBICs. The TX module type is
used to connect to twisted pair (copper). With the TX module, the required cable connector type is
indeed RJ45 and the maximum distance is that of standard twisted pair (100 meters).
If desired, TX modules can be used to provide the failover connection. This is not traditionally done,
however, because the SX modules are less expensive and have a greater maximum distance.
The TX module can only be used at 1000 Mbps: there is currently no option to run the TX module at
10/100 Mbps.
Cable failover through a network device
Do not connect the heartbeat cables through an external network device.
To keep overhead low and throughput high, the Sensors do not include layer 2 or 3 headers on the
packets they pass over the heartbeat connection, and they pass data larger than the standard
Ethernet maximum frame size (1518 bytes).
If you attempt to place a network device, such as a switch or router, between the heartbeat ports, the
heartbeat connection will fail.
Verification of the fail-over configuration
The final steps are to:
•
Confirm the Sensors are communicating over the heartbeat connection.
•
Test the fail-over setup.
McAfee Network Security Platform 8.1
IPS Administration Guide
133
6
How to configure Sensors for high availability
Verification of the fail-over configuration
Sensor communication confirmation
After the failover pair has been configured, failover peer status errors will appear on the System
Health monitor in the Manager Dashboard page for the selected admin domain (if enabled). You can
also view this information by going to Manage | <Admin Domain Name> | Troubleshooting | System Faults. The
errors continue to appear until you connect the heartbeat cables.
Option
Description
1
Fault type
2
Actions
The status of the communication between the Sensors can be monitored on the Sensors/View Details
page of the Web-based user interface or directly from the CLI of either Sensor.
The Sensors represented by the figure Running cables might therefore be properly connected, but just
need to be restarted.
From within the CLI, you can instead run the command from either Sensor. The output includes the
failover Enabled and Peer Status fields. The former indicates whether the Sensor at hand has been
configured to be part of a failover pair, and the latter shows the current state of the communication
between the two Sensors:
Figure 6-17 Sensor CLI show failover-status window
In the figure Sensor CLI show failover-status window, the Sensor is part of a failover pair, and
the pair is successfully communicating over the heartbeat connection.
Test failover setup
Once communication between the Sensors has been confirmed, the failover configuration should be
tested.
The way in which the configuration is best validated will vary from setup to setup, but these tests
should be similar to the ones performed after the Sensors were physically installed on the network.
The key differences this time include the following:
134
•
In the specific case in which the network at hand has two active paths that route asymmetrically,
the intrusion tests that previously failed should now be successful because both Sensors are
analyzing all packets from all flows.
•
Existing session state should not be lost when a Sensor goes offline.
McAfee Network Security Platform 8.1
IPS Administration Guide
6
How to configure Sensors for high availability
Network scenarios for Sensor high availability
The most precise way to confirm that the session remained intact after the "failure" is to capture and
analyze packets. A more rudimentary test is to open a browser and start a large download while one
Sensor is taken offline. If the state is successfully kept, there will be no fatal interruption in the
download process.
If the state is lost, confirm that the Sensors are indeed communicating with each other.
If the Sensors are not communicating, try the following steps in the order shown:
Task
1
Cold start both Sensors.
2
Reconnect the cables between them.
3
Recreate the failover pair.
4
If GBICs are used, confirm that McAfee supplied them.
Non-McAfee GBICs are known to create problems. If the GBICs used are not from McAfee pricelist,
temporarily swap them out for those that are before spending more time troubleshooting.
If they are communicating:
•
Capture packets simultaneously on both redundant paths. This will provide a full picture of the
data flow, and no doubt insight into the problem.
Network scenarios for Sensor high availability
In the below use-case scenarios, the term active/passive refers to network topology and not the
Sensor High Availability (HA) configuration. In Sensor HA, both the Sensors are in active/active state
meaning both the Sensors will process traffic received on their respective monitoring ports.
I-4010 Sensor in load balanced configuration
Scenario:
Two I-4010 Sensors are in load-balanced configuration. Each Sensor is monitoring an active 1GB full
duplex link - 500 Mbps in both directions- so each Sensor is handling 1Gbps of traffic. That is the total
2 Gbps throughput for each Sensor is utilized.
Will the total throughput that the Sensors need to handle is more, i.e. will the pair scan 4 Gbps of
traffic when combined?
Solution:
When used in the High Availability mode, the total aggregate throughput of Sensor pair remains the
same as in the standalone mode. i.e., Total throughput capability of the pair <= the quoted
throughput rate of the single Sensor. This remains the same when the total traffic is not evenly
distributed across the Sensors.
For example, an I-4010 will scan for 2Gbps in standalone mode, as well as HA mode.
If X is the throughput of one Sensor and Y is the throughput of the second Sensor,
X +Y <= the quoted throughput rate of the Sensor model. Suppose X = 2Gbps and Y = 2Gbps, so the
total is 4 Gbps, which exceeds the limit of the total throughput capability of 2Gbps that the pair can
handle.
McAfee Network Security Platform 8.1
IPS Administration Guide
135
6
How to configure Sensors for high availability
Network scenarios for Sensor high availability
Both Sensors share all data they receive on their monitoring ports with their peers and, most
importantly, both Sensors process the data they receive from their peers. So when you count how
much data an individual Sensor in HA mode is seeing per second, you have to include both the data it
is receiving on its monitoring ports as well as the data it is receiving from its peer via the HA /
interconnect ports.
I-4010 Sensor in active/active HA mode
Scenario:
Suppose there are two I-4010's in active/active HA mode with 500Mbps of traffic in both directions
(full duplex), then how does the pair work?
Solution:
Each 4010 can scan up to 2 Gbps at any time -standalone or part of an HA pair.
In the above case, the aggregate throughput for the pair would be 2Gbps - processed on each Sensor.
As long as the traffic on the monitoring ports of the Sensor on both the active links stays at or below
an aggregate rate of 2 Gbps, the deployment works fine.
I-4010 Sensor in active/passive HA mode
Scenario:
Suppose there are two I-4010's in active/passive HA mode with 1 Gbps throughput in full duplex
(500Mbps of traffic in both directions), then how does the pair work?
Solution:
In the above case, the aggregate throughput for the pair would be 2Gbps - 2 Gbps on the active
Sensor and 0 Gbps on the passive Sensor.
In this scenario, the Sensor on the active link receives 1 Gbps of traffic on its monitoring ports and
nothing on its HA ports, because the other Sensor is on the passive link. The Sensor on the Active link
sends a copy of the 1 Gbps of traffic to its peer and processes the same traffic without issue- because
1 Gbps is only 50% of the single Sensor throughput.
The 500 Mbps of traffic in each direction, i.e., total 1 Gbps of traffic is well under what the I-4010
Sensor can handle. Even if the 1 Gbps link is fully saturated, the total would be 2 Gbps in full duplex
and this can be handled by the Sensor.
136
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Enterprises are moving towards virtual IT infrastructures such as private and public cloud, virtual data
centers for servers, and virtual machines for clients. Security requirements for a virtual network might
vary vastly when compared to physical networks. For example, monitoring of peer-to-peer traffic and
access control in a virtual network have their own challenges. Based on the network architecture and
security requirements, virtual security products are required to protect virtual IT infrastructures. Even
for physical networks, virtual security products can bring in savings in terms of cost and space.
A Virtual IPS Sensor (Virtual Sensor) is McAfee's virtual next-generation IPS product. It is a virtual
instance of the NS-series Sensor software, which you can install as a virtual appliance on a VMware
ESX server. You do not require the Sensor hardware to deploy a Virtual Sensor. Though primarily
designed to protect virtual networks, you can deploy a Virtual Sensor to protect physical networks as
well.
In this document, the terms Virtual IPS Sensor and Virtual Sensor are interchangeably used.
The Virtual IPS Sensor is available as an OVA image. Open Virtualization Format (OVF) is an open
standard across various virtualization platforms, for packaging and distributing the software to be run
on virtual machines. An OVF virtual machine consists of a folder containing virtual machine files and a
file describing them. An Open Virtualization Appliance (OVA) file is a single compressed file that
contains the contents of an OVF folder.
Similar to a physical Sensor, you use a Manager to configure and manage Virtual Sensors. This
Manager can be installed on a physical server or on a virtual machine. Also, you can use the same
Manager to manage both virtual and physical Sensors including heterogeneous Sensor environments.
A Virtual Sensor supports most of the features that are supported by a physical Sensor. Except for the
fact that you deploy Virtual Sensors in a virtual environment, the process of configuring and managing
them is similar to that of physical Sensors. Virtual Sensors also function similar to their physical
counterparts when it comes to protecting your networks. With the added advantage of being a virtual
instance, you can deploy a Virtual Sensor to protect various network architectures. Some of the
common scenarios are covered in this document.
You install a Virtual Sensor in an VMware ESX server. Then, you can deploy this Virtual Sensor to
inspect traffic between:
•
Virtual machines (VMs) on this ESX server.
•
VMs on different ESX servers and the VMs on this host.
McAfee Network Security Platform 8.1
IPS Administration Guide
137
7
Virtual IPS Sensor deployment
•
Physical machines and the VMs on this ESX servers.
•
Physical networks wherein this ESX server is inline.
Figure 7-1 Virtual Sensor deployment
To use the information in this document, familiarity with the following might be required:
•
Administration of VMware ESXi hosts including virtual networks within VMware ESXi hosts.
•
Management of guest virtual machines.
•
Installation, configuration, and management of Network Security Sensor and Manager.
Contents
Virtual Sensors - advantages
Virtual IPS Sensor models
138
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Virtual Sensors - advantages
Requirements for deploying Virtual Sensors
Considerations
Deploying Virtual Sensors
Generate the Virtual IPS Sensor License Compliance report
Virtual Sensors - advantages
•
As with any virtual technology, Virtual Sensors too bring in savings in terms of space, cost of the
appliance, maintenance costs, power to run the appliances, power for air-conditioning, and so on.
•
Virtual Sensors enable inspection of traffic that never leave an ESX server. Also, you can implement
security policies, (Exploit, DoS, Firewall, Advanced Malware policies) on this traffic.
•
Virtual Sensors are very easy and quick to deploy. Therefore, they can scale up to any rapid
expansions of your virtual network.
•
You can deploy Virtual Sensors without any physical access to the ESX server.
•
Though protecting virtual networks has its unique challenges, there is no compromise on security
with respect to Virtual Sensors. It protects networks similar to a physical Sensor, including features
such as application identification and visualization, Firewall policies, Advanced Malware policies and
so on. Also, just like physical Sensors, a Virtual Sensor can integrate and communicate with other
McAfee products.
•
Based on factors such as the size of your network and network architecture, it is possible to use
Virtual Sensors to protect both your virtual and physical networks.
•
You can use the same Manager as a single-point-of-control for managing your physical and Virtual
Sensors.
•
Provides the flexibility of using virtual, physical, or a mixture of virtual and physical Sensors to
protect your networks.
•
Managing Sensors is simplified and centralized.
•
You can define the security policies to both virtual and physical networks at one place. So, the
task of defining and implementing security policies for the virtual networks still rests with your
security experts.
•
Provides a consolidated view of the threat information from both virtual and physical Sensors.
•
Enables consistent and consolidated report generation for all your networks.
This Manager can also be installed on a VM.
•
Virtual Sensors are self-contained with respect to protecting your networks. That is, there is no
requirement for any third-party applications to protect virtual or physical networks.
•
Virtualization of virtual ports is available. That is, you can virtualize the interfaces of a physical
Sensor by creating sub-interfaces based on VLAN or CIDR. Following the same procedure, you can
create sub-interfaces of the monitoring ports of a Virtual Sensor.
Virtual IPS Sensor models
The table describes the available Virtual IPS Sensor models.
McAfee Network Security Platform 8.1
IPS Administration Guide
139
7
Virtual IPS Sensor deployment
Requirements for deploying Virtual Sensors
Model
Maximum
Sensor
throughput
Number of
monitoring
ports
Management
port
Response
port
Logical
CPU
Cores
Memory
Storage
IPS-VM100 100 Mbps
4
1
1
3
6 GB
minimum
required.
50 GB
IPS-VM600 600 Mbps
6
1
1
4
6 GB
minimum
required.
100 GB
The kind of traffic being inspected and the features that you enable are some of the primary factors that
affect the throughput of a Sensor. For these details and other capacity values for Virtual Sensors, see
the Virtual IPS Sensor capacity by model number section in the Network Security Platform 8.1 Best
Practices Guide.
Requirements for deploying Virtual Sensors
This section discusses the server requirements for deploying Virtual Sensors.
VMware ESX server requirements
Component
Minimum requirement
Virtualization
software
VMware ESX 5.0 and above.
Tunneled traffic does not work with ESX 5.5 with E1000 card.
CPU
• Intel Xeon processor 5000 series or better.
• The minimum required processor speed is 1 GHz; recommended is 2 GHz or
more.
• 3 or 4 logical CPU cores based on the Virtual Sensor model.
• Minimum 4 Ethernet ports; recommended is 6. More Ethernet ports enable you
to use that many Ethernet port pairs as monitoring port pairs.
Other requirements
•
To install the Virtual Sensor, that is to deploy the OVA file, you need VMware vCenter Server. Using
the VMware vSphere Client to deploy the Virtual Sensor OVA file is not recommended. For
subsequent management of your VMware ESXi server, you might use VMware vSphere Client.
The procedures explained in this document were documented using VMware vCenter Server Version:
5.1.0.10100 Build 1123965 and VMware vSphere Web Client Version 5.1.0 Build 1063329.
140
•
Network Security Manager 8.1.x or later installed on a virtual or physical machine.
•
You require one license per Virtual Sensor. The license is also specific to the Virtual Sensor model
you purchased. Make sure you have secured the required number of licenses from McAfee.
•
You must exclude the Virtual Sensor from VMware Distributed Resource Scheduler (DRS).
•
Do not install VMware tools for a Virtual Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Considerations
•
For optimal and predictable performance follow the below guidelines.
•
You must configure each Virtual Sensor VM to execute on as many cores as required for the
Sensor model by assigning CPU affinity to the VM. For example, an IPS-VM100 VM must be
affinitized to 3 logical cores.
•
No other virtual machines running on the same ESXi host can be allowed to share the CPU cores
that are assigned to a Virtual Sensor virtual machine. For example, if there are 16 CPU cores on
a ESX server, the Virtual Sensor VM can be affinizied to the first 3 CPUs. All other VMs running
on the same ESX server must be excluded from using the first 3 CPUs by affinitizing them to
use the remaining CPUs on the host.
Considerations
Review this section and its sub-sections before you deploy a Virtual Sensor.
•
Based on how you deploy the Virtual Sensor, you might have to re-configure some of the vSwitches
on your VMware ESXi host.
•
Currently, Virtual Sensors are not VMware vMotion aware. That is, you cannot move a Virtual
Sensor between VMware ESXi hosts. You must manually deploy the Virtual Sensor in the other
VMware ESXi hosts.
•
Currently, Virtual Sensor deployment involves only standard vSwitches and not distributed
vSwitches.
•
You need an Active Fail-Open kit to deploy Sensor monitoring ports in fail-open mode. This is
applicable to scenarios where the Virtual Sensor is between two physical network devices. For inline
inspection of traffic to virtual machines, only fail-closed mode is applicable.
•
Currently, failover-deployment of Virtual Sensors is not supported.
Under test conditions, it is observed that it takes less than a minute for a Virtual Sensor to restart
and become fully operational again. This factor mitigates the risk of significant network disruption
due to inline Virtual Sensor monitoring ports going down. It is recommended to deploy Active
Failopen Kit to avoid network disruption due to a restart of Virtual sensor.
Supported modes for Virtual Sensor
You can deploy a Virtual Sensor in the following modes:
•
SPAN mode.
•
Inline fail-closed mode.
•
For inline fail-open mode, you must use an external Active Fail-Open Bypass Kit.
Tap mode is not applicable to Virtual Sensors.
Features supported by a Virtual Sensor
Table 7-1 Supported features
Feature name
IPS policies for exploit attacks
IPS policies and DoS policies for detection of DoS attacks
DNS DoS protection
McAfee Network Security Platform 8.1
IPS Administration Guide
141
7
Virtual IPS Sensor deployment
Considerations
Table 7-1 Supported features (continued)
Feature name
Reconnaissance policies
Quarantine (automatic, through IPS policies as well as manual from the Real-time Threat Analyzer)
MDR
Virtual Sensor monitoring ports based on CIDR and VLAN
Snort custom attack definitions
McAfee custom attack definitions
Protection of Web application servers
Advanced Traffic Inspection
Inspection of Q in Q traffic
Layer 2 passthru mode is supported but implemented differently when compared to physical Sensors
Layer 7 data collection
SYN cookie protection
ARP spoofing protection
IP spoofing protection
Virtualization of monitoring ports using VLANs and CIDRs (VIDS)
MPLS traffic inspection
IPv6 traffic inspection
IPv6 support for the management port
Inspection of tunneled traffic including GRE tunneled traffic
Tunneled traffic does not work with ESX 5.5 with E1000 card.
HTTP response scanning
Inspection of double VLAN tagged traffic
Monitoring Sensor performance
Synchronization of Sensor clock using an NTP server
Display Sensor CLI audit log events in the Manager
TACACS+ user in audit logs
Secure Transfer of Files from Sensor CLI
Application Identification and Visualization
Firewall policies
Advanced Traffic inspection
SmartBlocking of attacks including use of IP Reputation to augment SmartBlocking
Integration with McAfee GTI for IP reputation and file reputation. This includes protection from
high-risk hosts.
Connection Limiting policies
Inspection of X-Forwarder-For Header Information. Reputation lookup and quarantine of client IP
addresses in the XFF header.
Layer 7 Data Collection
Stateless Firewall access rules
Simulated Blocking
142
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Considerations
7
Table 7-1 Supported features (continued)
Feature name
Latency monitor
Granular access control for CLI commands (for TACACS users)
Advanced Malware policies including integration with McAfee Advanced Threat Defense and NTBA
Appliances
Advanced botnet detection including Bot Command and Control server activity detection
Network forensics
Passive device profiling
Web server protection against DoS attacks
Traffic prioritization
Netflow export to NTBA
Integration with McAfee Endpoint Intelligence Agent
Sensor autorecovery — Since a Virtual IPS Sensor cannot depend on its software to go to layer2
during recovery, the traffic is interrupted until all applications are restarted and the Sensor is back to
GOOD health.
After you deploy a Virtual Sensor, the process of configuring and managing it is similar to that of a
physical Sensor. Therefore, refer to the corresponding section for information on how to configure the
supported features.
Features not supported by Virtual Sensors
Table 7-2 Features not supported
Feature name
SSL decryption
VLAN bridging
Sensor failover
Hitless reboot
QoS policies
Capture data packets (packet capture)
Jumbo frame parsing
IPS for mobile networks
Offline signature set and Sensor software download
Features that are not applicable to Virtual Sensors:
•
Tap mode
•
Periodic inline restore from bypass mode
•
Default IP for the Sensor management port
•
Port clustering
McAfee Network Security Platform 8.1
IPS Administration Guide
143
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
Deploying Virtual Sensors
To deploy Virtual Sensors, you must first install the Virtual Sensors and establish trust with a Manager.
After trust is established, you can deploy the Virtual Sensor for protecting your networks. How you
configure the Virtual Sensor, however, depends on the network architecture and your security needs.
The following is a high-level procedure that you can consider to install and subsequently deploy a
Virtual Sensor:
1
Verify your ESX server meets the hardware and software requirements. See Requirements for
deploying the Virtual Sensor.
2
Install the Virtual Sensors and establish a trusted communication channel between the Virtual
Sensors and a Manager. See Installing Virtual Sensors.
3
Determine how you want to deploy the Virtual Sensor and configure it accordingly. See Deployment
scenarios for Virtual Sensors.
Installing Virtual Sensors
Before you can deploy a Virtual Sensor to protect your network, you must install the Virtual Sensor
and establish trust between the Virtual Sensor and the Manager.
The following are the high-level steps to install a Virtual Sensor:
1
Identify the network to which you in which you want to place the Virtual Sensor and the Manager.
Accordingly, identify the vSwitch and the port group for the management port and the Manager.
You can use the default switch port group of vSwitch0, which is VM Network, to connect the Sensor
management port. However, if required, you can also create a vSwitch to connect the management
port. To create a vSwitch for management port connectivity, see Create a standard vSwitch for the
management port.
2
For every Virtual Sensor that you plan to deploy, import the required licenses in the Manager. See
Import the Virtual IPS Sensor licenses.
3
Add the Virtual Sensor in the Manager. See Add the Virtual Sensor in the Manager.
4
Install the Virtual Sensor and establish trust with the Manager. See Install the Virtual Sensor.
Create a standard vSwitch for the management port
Before you begin
To create a vSwitch, you might be required to connect an additional physical NIC on the
ESX.
After you install the Virtual Sensor, you need a standard vSwitch to which you connect the
management port of the Virtual Sensor. If you have installed the Manager on the same ESX, you can
connect it to this switch as well. When you create a standard vSwitch, ESX creates a default port
group for this vSwitch.
Task
1
Connect an additional physical NIC on the ESX to the adjacent physical switch.
This is required for the vSwitch that you are creating.
144
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
2
Log on to the ESX as the root user in VMware vSphere Web Client.
3
In the vSphere Home tab, select Hosts and Clusters.
4
Select the required ESX server and select Manage | Networking | Virtual switches.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
145
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
5
Click on the Add host networking icon.
6
For Select connection type, as an example select Physical Network Adapter and click Next.
Selecting the connection type depends on your network design and requirements. For example, if
the Manager is installed on a physical machine, then you must select physical network adapter. If
not the Sensor and the Manager cannot communicate. If the Manager is installed on a virtual
machine and you plan to use the same vSwitch for both the Sensor management port and the
Manager, then you might choose Virtual Machine Port Group for a Standard Switch. For the scenarios
explained in this document, select Physical Network Adapter.
7
146
For Select target device, select New standard switch, the required number of ports, and then click Next.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
8
For Create a Standard Switch step, click on the Add adapters icon.
9
In the Add Physical Adapters to the Switch dialog, select the required network adapter and click OK.
Make sure that a physical NIC corresponding to the network adapter you selected is connected to
the network.
McAfee Network Security Platform 8.1
IPS Administration Guide
147
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
10 Verify the properties of the selected adapter and click Next and then select Finish.
The vSwitch that you created is listed in the Virtual switches section.
11 Add the required switch port groups for the vSwitch that you created; select that vSwitch and then
click on the Add host networking icon.
12 In the Select connection type step, select Virtual Machine Port Group for a Standard Switch and then click Next.
148
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
13 In the Select target device step, select Select an existing standard switch and make sure the vSwitch that you
created is selected. Then click Next.
14 In the Network Label field, enter the required name for the default port group that the wizard creates
for the switch.
You can modify Network Label later. For easier management, you can name it as Management Port
Group.
15 Optionally, in VLAN ID field, select All (4095) and select Next.
If required, you can specify the required VLAN ID as per your network configuration.
16 Review the details displayed in the Ready to complete step and click Finish.
This vSwitch is now listed with the switch port group that you created.
McAfee Network Security Platform 8.1
IPS Administration Guide
149
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
17 Move the mouse over the physical adapter and click on it.
18 Click on the Edit adapter speed icon.
19 Verify if the Configured Speed, Duplex is set to Auto negotiate.
For other property values, you can leave them with the default values.
150
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
Manage Virtual IPS Sensor licenses
Before you begin
•
The license file that you received from McAfee is accessible from your Manager client.
•
You have access to the root-admin domain in the Manager.
Virtual Sensors are licensed per installation. You need to secure a license per Virtual Sensor managed
by a Manager. Also, licenses are model-specific. Licenses apply to all Virtual Sensor models. McAfee
provides license files that you can import into the Manager. Each license file will contain the number of
supported virtual IPS sensors.
One license file might contain one or more licenses. Before you deploy Virtual Sensors, it is a good
practice to first import the required licenses into the Manager. You can import and delete Virtual
Sensor license files from the Virtual IPS Sensor Licenses page. This page is available only in the root
admin domain. So, even for the Virtual Sensors managed by child domains, the license file is imported
only in the root admin domain.
The Manager periodically checks if there are enough licenses imported already. If there are not enough
licenses, then this information is displayed in the License Summary section of the Virtual IPS Sensor
Licenses page. Also, a critical system health fault message is raised for the Manager. The Manager
periodically checks the number of licenses against the installed number of Virtual Sensors and raises
this fault message accordingly.
Figure 7-2 Virtual Sensor license-non-compliance fault message
Notes
•
There is no option currently to export license files from a Manager. So, make sure you safely retain
the license files that you received from McAfee.
•
You cannot import the Virtual Sensor licenses in the Central Manager.
•
In case of MDR, you must import the license file in the currently active Manager. This license file is
pushed to the peer as part of data synchronization.
•
To increase the number of licenses, simply import additional license files provided by McAfee.
•
If you want to transfer a part of the licenses to a different Manager, you must contact McAfee
Support.
•
If you delete a license file, and if the number of licenses is less than the number of Virtual Sensors
managed, then the License Summary information is displayed accordingly.
•
Consider you want to move a Virtual Sensor to a different Manager Server. Delete the license file in
the source Manager and then import that license file in the target Manager. Then, de-install the
Sensor from the source Manager and then install it with the target Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
151
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
•
If you enable GTI participation, then the following information is sent to McAfee Global Threat
Intelligence (McAfee GTI):
•
Number of Virtual Sensor licenses required to be compliant.
•
Number of currently managed Virtual Sensors.
•
Total number of licenses currently imported.
You can verify this by clicking Show Me What I'm Sending in the Global Threat Intelligence page (Manage | root
admin domain | Integration | Global Threat Intelligence).
•
If you want to generate a report on your compliance with respect to Virtual Sensor licenses, you
can generate the Virtual IPS Sensor License Compliance report.
Task
1
In the Manager select Manage | root admin domain | Setup | Virtual IPS Sensor Licenses.
Figure 7-3 Virtual IPS Sensor Licenses page
152
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
2
7
To import licenses, click Add, browse to the .zip or .jar file containing the licenses, and then click OK.
Figure 7-4 Virtual IPS Sensor Licenses added
McAfee Network Security Platform 8.1
IPS Administration Guide
153
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
To delete a license file from the Manager, select the required license file and click Remove.
4
Click OK to confirm deletion.
If deleting the license file results in non-compliance, an alert message is displayed and you must
click OK to proceed.
Table 7-3 Option definitions
Option
Description
License Status
Indicates the current compliance status.
Total Number of Virtual IPS
Sensors Allowed
This number quantifies the number of Virtual Sensors that can be under
this Manager.
Total Number of Virtual IPS
Sensors Managed
Indicates the number of Virtual Sensors currently managed by the
Manager.
License Key
Displays the license key of the license file.
Generated
The date when the license file was generated.
Customer
The customer for whom the license file was generated.
Grant ID
The McAfee Grant ID of the corresponding customer.
Allowed Virtual IPS Sensors
This corresponds to the number of licenses per license file.
Imported Time
The timestamp of when the license file was imported into the Manager.
Imported By
The user who imported the license file.
Comment
Enables you to add your comment per license file that is imported.
Double-click in the Comment field and enter your comment. Click outside
this field and the your comment is automatically saved.
Add
Click to import a license file.
Remove
Select a license file and then click Remove to delete a license file from
the Manager.
Figure 7-5 Details of the imported license files
Add the Virtual Sensor in the Manager
Before you begin
You have a Manager version 8.0.7.x or later either on a virtual or a physical machine.
You can add the Virtual Sensor in the Manager and specify a shared secret key. You can use a Manager
installed on a VM or on a physical server.
Task
154
1
In the Manager select Devices | <Domain name> | Global | Add and Remove Devices.
2
Click New.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
4
7
Specify at least the Device Name, Device Type, and Shared Secret.
•
Select IPS Sensor as the Device Type.
•
You must use the same Device Name and Shared Secret when you deploy the Virtual Sensor.
Click Save.
Figure 7-6 Virtual Sensors added in a Manager
For more information on deleting a configured Sensor, see topic Delete a Sensor from the Manager,
section How to replace a Sensor, chapter Troubleshooting in McAfee Network Security Platform IPS
Administration Guide.
Install the Virtual Sensor
Before you begin
•
The Virtual Sensor installation file is a .ova file. Make sure this file is accessible from
your client machine.
•
Standard vSwitches and switch port groups are available for the Sensor management
port and monitoring ports that you plan to use. Consider that you are installing
IPS-VM100, which has one management port, one response port, and 4 monitoring
ports. Currently you plan to deploy ports 1-2 in inline mode between 2 vSwtiches. You
do not plan to use ports 3 and 4 for now. For this example, make sure you have the
following:
•
•
Standard vSwitch with switch port group for the management port. The Sensor must
be able to communicate with the Manager through this switch port group.
•
Two standard vSwitches with switch port groups for monitoring port 1 and 2. That is,
the Sensor will act as a bridge between these two vSwitches with port pair 1-2 inline
between these two vSwitches.
•
Different dummy switch port groups for the Sensor ports that you do not plan to use
now — response port and monitoring ports 3 and 4.
You have added the Virtual Sensor in the Manager.
Task
1
Log on to the ESX as the root user in VMware vSphere Web Client.
McAfee Network Security Platform 8.1
IPS Administration Guide
155
7
156
Virtual IPS Sensor deployment
Deploying Virtual Sensors
2
In the vSphere Home tab, select Hosts and Clusters.
3
Navigate to the required node such as a resource pool, right-click, and select Deploy OVF Template.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
4
Click Browse and locate the .ova file.
5
Review the details and click Next.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
157
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
6
In the Name field, enter a name for the Sensor and also select the corresponding datacenter.
Preferably enter the same name that you entered when adding the Sensor in the Manager.
7
From the Select virtual disk format list, select Thin Provision.
8
In the Setup networks section, select the switch port groups for the corresponding Sensor ports.
•
For example scenario 2 for example, assign VNSP Client Port for monitoring port 1 and VNSP
Server Port for monitoring port 2.
•
Assign temporary, non-functional switch port groups to the unused Sensor ports, that is the
response port and ports 3 and 4 (for scenario 2). You select a functional switch port group for
the response port when you configure the Virtual Sensor for IDS (SPAN).
You must never assign the same port group to peer monitoring ports. For example, monitoring
ports 3 and 4 must not be assigned the same port group. If you do, it results in a loop within the
ESX.
•
For the management port, assign the port group belonging to the vSwitch that you created for
the Sensor management port. This switch port group must enable communication with the
Manager server.
Within the same Virtual Sensor, no Source (monitoring port or the response port) should have the
same Destination (switch port group) as that of the Sensor management port.
158
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
9
7
In the Customize template page, specify the Sensor setup details.
a
Enter the same Sensor name that you specified in the Manager.
b
Optionally, enter the IPv4 address for the Sensor.
You can specify IPv4, IPv6, or both type of IP addresses to the Sensor.
c
If you had specified an IPv4 address, specify the subnet mask for the IPv4 address that you
provided.
d
If you had specified an IPv4 address, specify the default gateway for the IPv4 address.
This is mandatory if the Sensor needs to communicate outside its network. For example, the
Manager could be on a different subnet.
e
Optionally, specify an IPv6 address to the Sensor.
f
If you had specified an IPv6 address, specify the default gateway for the IPv6 address.
g
Specify the IPv4 or IPv6 address of the hypervisor such as VMware ESX server on which you are
deploying the Virtual Sensor.
h
Specify the Manager's primary IPv4 or IPv6 address.
To specify the Manager's secondary IP address, use the set manager secondary ip command
in the Sensor CLI after the Sensor is installed.
McAfee Network Security Platform 8.1
IPS Administration Guide
159
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
i
Specify the shared secret key and also confirm it by re-entering.
j
Click Next.
10 Review the configuration that you specified, select Power on after deployment, and then click Finish.
Click Back and make changes, if required. Note that the Sensor setup details that you entered are
listed under Properties.
160
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
11 After the Virtual Sensor is installed, open an SSH client session to logon to the Sensor.
Alternatively, you can click Launch Console in the vSphere Web Client.
12 In the Sensor CLI, enter admin and admin123 as the login name and password respectively.
13 Use the status CLI command to check if trust is established with the Manager and if signature set
is present in the Sensor.
If the signature set is not present, you can deploy the signature set from the Deploy Pending Changes
page of the Manager.
Configure CPU affinity for Virtual Sensors
Before you begin
You have installed the Virtual Sensor.
For optimal and predictable performance of Virtual Sensors, you must follow the below guidelines.
•
You must configure each Virtual Sensor VM to execute on as many cores as required for the Sensor
model by assigning CPU affinity to the VM. For example, an IPS-VM100 VM must be affinitized to 3
logical cores.
•
No other virtual machines running on the same ESXi host can be allowed to share the CPU cores
that are assigned to a Virtual Sensor virtual machine. For example, if there are 16 CPU cores on a
ESX server, the Virtual Sensor VM can be affinizied to the first 3 CPUs. All other VMs running on the
same ESX server must be excluded from using the first 3 CPUs by affinitizing them to use the
remaining CPUs on the host.
McAfee Network Security Platform 8.1
IPS Administration Guide
161
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
Task
162
1
Use the shut CLI command to shutdown the Virtual Sensor and also make sure in the VMware
vSphere Web Client that the Virtual Sensor is powered off.
2
Log on to the ESX as the root user in VMware vSphere Web Client.
3
In the vSphere Home tab, select Hosts and Clusters.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
4
Under the corresponding ESX, select the required Virtual Sensor and select Edit virtual machine settings.
5
In the Edit Settings dialog, click CPU.
McAfee Network Security Platform 8.1
IPS Administration Guide
163
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
6
From the HT Sharing drop-down, select the required option.
HT sharing means hyperthreaded core sharing.
•
None — For best, optimal, and predictable performance, McAfee recommends this option.
•
Internal — Better, less optimal, and less predictable performance is expected with this option.
•
Any — Normal performance, which is less optimal than Internal and sometimes even unpredictable
is expected with this option.
For the description of these options and to know the difference between them, refer to VMware
documentation
7
In the Scheduling Affinity text box enter the logical CPU affinities for the Virtual Sensor.
The string that you enter depends on the Virtual Sensor model. For example, IPS-VM600 uses 4
logical CPU cores. So, in the snap above, 5-8 indicates processors 5, 6, 7, and 8.
8
Click OK.
9
Power on the Virtual Sensor in VMware vSphere Web Client.
Deployment scenarios for Virtual Sensors
There are subsections that describe some scenarios for you to understand various deployment options.
These scenarios are examples used for the sake of explanation; they might not exactly match real or
typical network architectures. You can use the scenarios to determine the Virtual Sensor deployment
process for your network. As an ESX administrator, your must identify a process that requires the least
amount of changes to your network architecture and configuration.
164
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
The following is a high-level procedure that you can consider to deploy a Virtual Sensor:
1
2
3
Determine how you want to deploy the Virtual Sensor. You can review the scenarios discussed in
the subsections. When deciding the deployment type, you can factor in:
•
The kind of protection that your network requires. For example, whether you need to place
monitoring ports in inline mode against SPAN mode.
•
How to deploy the Virtual Sensor with the least changes to your ESX configuration.
Follow the procedural information provided for the corresponding scenario.
a
Evaluate your ESX deployment and identify the vSwitches that need to be modified and those
that need to be created.
b
Evaluate the port groups that can be used and the ones that need to be created.
c
Identify the vSwitches and port groups for the Sensor monitoring ports.
d
Identify the vSwitches and port groups for the clients and servers that you need to protect.
Verify if the deployment is functioning as expected. See Verify the deployment.
Scenario 1: Inspection of traffic between virtual machines in SPAN mode
This scenario involves using a SPAN monitoring port to inspect traffic between virtual machines on the
same ESX. Similar to the SPAN mode deployment of a physical Sensor, the SPAN mode deployment of
a Virtual Sensor is also simple and non-intrusive.
Scenario description before Virtual Sensor deployment
•
The servers are installed on guest VMs on the ESX.
•
These servers are connected to a standard vSwitch, vSwitch0.
•
vSwitch0 has a physical adapter, which is connected to networks outside the ESX.
Scenario description after Virtual Sensor deployment
•
In vSwitch0 create a new switch port group set in promiscuous mode.
•
The Virtual Sensor is deployed on the ESX.
•
Consider that the Manager is installed on a VM connected to vSwitch1.
McAfee Network Security Platform 8.1
IPS Administration Guide
165
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
•
In this scenario, the Manager is connected to the management port of the Virtual Sensor through
vSwitch1. This vSwitch1 has a physical adapter vminc1. So, you can access the Manager and the
Sensor from outside the ESX.
•
Monitoring port 1 of the Virtual Sensor is in SPAN mode. This is connected to the promiscuous
switch port group in vSwitch0. Therefore, a copy of all the packets of vSwitch0 are sent to port 1
for intrusion detection.
Figure 7-7 Scenario after Virtual Sensor deployment
Scenario 1: High-level steps for Virtual Sensor deployment
This section assumes the following for deploying the Virtual Sensor for scenario 1.
•
The ESX server meets the requirements as discussed in Requirements for deploying Virtual Sensors
on page 140.
•
You have the privileges on the ESX server to add and modify vSwitches and port groups.
•
You have installed the Virtual Sensor and established trust with the Manager successfully. As an
example in this scenario, the management port is connected to vSwitch1.
•
As an example, this section uses the IPS-VM100 Virtual Sensor to explain the deployment.
•
This scenario involves only a Sensor monitoring port deployed in SPAN mode.
•
This section uses only the vSphere Client for configurations on the ESX.
Task
1
Modify vSwitch0 to create a switch port group in promiscuous mode.
Refer to Modify an existing standard vSwitch for a monitoring port on page 186. Subsequently, you
assign this switch port group to the SPAN port.
2
Modify vSwitch0 to create a switch port group.
Subsequently, you assign this switch port group to the Sensor response port.
3
166
Configure the SPAN port on the Virtual Sensor in the Manager.
a
Click the Devices tab.
b
Select the domain from the Domain drop-down list.
c
In the left pane, click the Devices tab.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
4
d
Select the device from the Device drop-down list.
e
Select Setup | Physical Ports.
f
Double-click on monitoring port 1 and then from the Operating Mode drop-down, select SPAN or Hub
(Single Port).
g
Click OK.
h
Click Save in the Configure Ports page.
i
Select Deploy Pending Changes and in the Deploy Pending Changes page select Configuration & Signature Set
for the required Virtual Sensor and click Update.
Assign the switch port groups you created in steps 1 and 2 to the Sensor SPAN port and the
response port respectively.
See Specify the switch port groups for monitoring ports on page 191.
5
Verify if you have deployed the Virtual Sensor correctly and whether it is inspecting traffic.
Refer to Verify the deployment on page 199.
Scenario 2: Inline inspection of traffic between virtual machines
This scenario involves inspecting the traffic between virtual machines on the same ESX.
Scenario description before Virtual Sensor deployment
•
The clients and servers belong to the same subnet (10.10.10.x).
•
The clients and servers are connected to different virtual machine port groups within the same
standard vSwitch (vSwitch0).
•
For the sake of this discussion, assume that the clients and servers have no access from outside
the ESX. That is, there is no physical NIC associated with vSwitch0.
Scenario description after Virtual Sensor deployment
•
Two more standard vSwitches (vSwitch1 and vSwitch2) are now added.
•
The Virtual Sensor is deployed on the ESX.
McAfee Network Security Platform 8.1
IPS Administration Guide
167
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
•
In this scenario, the Manager is installed on a VM connected to vSwitch2.
•
In this scenario, the Manager is connected to the management port of the Virtual Sensor through
vSwitch2. This vSwitch2 has a physical adapter vminc0. So, you can access the Manager and the
Sensor from outside the ESX.
•
The monitoring port pair 1-2 of the Virtual Sensor is inline between the client and server.
•
The client and the monitoring port 1 are connected to two different port groups within vSwitch0.
The port group to which the monitoring port is connected is set to promiscuous mode.
•
Similarly, the server and monitoring port 2 are connected to two different port groups within
vSwitch1. Any traffic from the client to the server is inspected by the monitoring port pair 1-2.
Scenario 2: High-level steps for Virtual Sensor deployment
This section assumes the following for deploying the Virtual Sensor for scenario 2.
•
The ESX server meets the requirements as discussed in Requirements for deploying Virtual Sensors
on page 140.
•
You have the privileges on the ESX server to add and modify vSwitches and port groups.
•
You have installed the Virtual Sensor and established trust with the Manager successfully. As an
example in this scenario, the management port is connected to vSwitch2.
•
As an example, this section uses the IPS-VM100 Virtual Sensor to explain the deployment.
•
This scenario involves only a Sensor monitoring port pair deployed in inline fail-closed mode.
•
This section uses only the vSphere Client for configurations on the ESX.
Task
1
Create vSwitch1 for connecting Sensor monitoring port 2 and the 10.10.10.16 server.
Refer to Create a standard vSwitch for a monitoring port on page 176.
2
Modify vSwitch0 to connect monitoring port 1.
Refer to Modify an existing standard vSwitch for a monitoring port on page 186.
168
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
7
Assign the corresponding switch port group (promiscuous mode) that you created in step 1 to
monitoring port 2.
See Specify the switch port groups for monitoring ports on page 191.
4
Change the switch port group for the 10.10.10.16 server such that it is now connected to vSwitch1.
5
Assign the corresponding switch port group (promiscuous mode) that you created in step 2 to
monitoring port 1.
See Specify the switch port groups for monitoring ports on page 191.
6
Verify if you have deployed the Virtual Sensor correctly and whether it is inspecting traffic.
Refer to Verify the deployment on page 199.
Scenario 3: Inspection of traffic to virtual servers
This scenario involves inspecting the traffic going to and coming out of virtual servers installed on an
ESX. In this deployment, the Sensor monitoring port acts as a gateway to the protected servers.
Scenario description before Virtual Sensor deployment
•
The servers are installed on guest VMs on the ESX.
•
These servers are connected to a standard vSwitch, vSwitch0.
•
vSwitch0 has a physical adapter, which is connected to networks outside the ESX.
Scenario description after Virtual Sensor deployment
•
Two more standard vSwitches (vSwitch1 and vSwitch2) are now added.
•
The Virtual Sensor is deployed on the ESX.
•
The Manager is installed on a VM connected to vSwitch2.
•
The management port of the Virtual Sensor is connected to vSwitch2. This virtual switch has a
physical adapter. So, you can access the Manager and the Sensor from outside the ESX.
•
The monitoring port pair 1-2 of the Virtual Sensor is inline between external network through
vmnic0 and the server farm on the ESX.
McAfee Network Security Platform 8.1
IPS Administration Guide
169
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
•
The servers and the monitoring port 1 are connected to two different port groups in vSwitch0. The
port group to which the monitoring port is connected is set to promiscuous mode.
•
Monitoring port 2 is connected to vSwitch1, which is in turn connected to external network through
vmnic0. Therefore, any traffic to the servers from the outside network is inspected by the port pair
1-2.
Note that the monitoring port 1 is connected to a promiscuous switch port group on vSwitch0.
Therefore, the Sensor will inspect traffic between Server 1 and Server 2 as well though it is not inline.
Effectively this is as if monitoring port 1 is in SPAN mode. To avoid the Sensor from inspecting the
traffic between the servers, define ACLs on the Sensor accordingly.
Scenario 3: High-level steps for Virtual Sensor deployment
This section assumes the following for deploying the Virtual Sensor for scenario 3.
•
The ESX server meets the requirements as discussed in Requirements for deploying Virtual Sensors
on page 140.
•
You have the privileges on the ESX server to add and modify vSwitches and port groups.
•
You have installed the Virtual Sensor and established trust with the Manager successfully. As an
example in this scenario, the management port is connected to vSwitch2.
•
As an example, this section uses the IPS-VM100 Virtual Sensor to explain the deployment.
•
This scenario involves only a Sensor monitoring port pair deployed in inline fail-closed mode.
•
This section uses only the vSphere Client for configurations on the ESX.
Task
1
Create a standard vSwitch for connecting Sensor monitoring port 2 with the external network
through vmnic0. For this scenario, consider it is vSwitch1.
Refer to Create a standard vSwitch for a monitoring port on page 176.
Make sure this vSwitch has a physical adapter and that this is connected to the corresponding
external switch.
2
Modify vSwitch0 to connect monitoring port 1 and the virtual servers.
For this scenario, you need not change the switch port group for the virtual servers. Create a new
switch port group for monitoring port 1. Refer to Modify an existing standard vSwitch for a
monitoring port on page 186.
170
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
Assign the corresponding switch port group (promiscuous mode) to the monitoring ports.
See Specify the switch port groups for monitoring ports on page 191.
4
•
The switch port group that you created in step 1 (vSwitch1) must be assigned to monitoring
port 2.
•
The switch port group that you created in step 2 (vSwitch0) must be assigned to monitoring
port 1.
Verify if you have deployed the Virtual Sensor correctly and whether it is inspecting traffic.
Refer to Verify the deployment on page 199.
Scenario 4: Inspection of traffic between physical machines
In addition to virtual networks, you can use the Virtual Sensor to protect physical networks as well.
This is typically used in very large networks, where space might be a constraint to install multiple
physical Sensors.
Scenario description before Virtual Sensor deployment
•
The clients and servers are connected to different physical switches.
•
For the sake of simplicity, assume that the client and servers are on the same VLAN.
•
The two switches are connected through their trunk ports. Since all the machines are assumed to
be on the same VLAN, no routing is required.
Scenario description after Virtual Sensor deployment
•
The trunk ports of the two switches are connected two physical NICs on the ESX.
•
These NICs are connected to two different vSwitches, which are in turn connected to monitoring
port pair 1-2.
•
vSwitch2 is used to connect the management port, which in turn is connected to a Manager on a
physical machine.
•
The monitoring port pair 1-2 of the Virtual Sensor is now inline between the client and the server.
McAfee Network Security Platform 8.1
IPS Administration Guide
171
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
Scenario 4: High-level steps for Virtual Sensor deployment
This section assumes the following for deploying the Virtual Sensor for scenario 4.
•
The ESX server meets the requirements as discussed in Requirements for deploying Virtual Sensors
on page 140.
•
You have the privileges on the ESX server to add and modify vSwitches and port groups.
•
You have installed the Virtual Sensor and established trust with the Manager successfully. As an
example in this scenario, the management port is connected to vSwitch2.
•
As an example, this section uses the IPS-VM100 Virtual Sensor to explain the deployment.
•
This scenario involves only a Sensor monitoring port pair deployed in inline fail-closed mode.
•
This section uses only the vSphere Client for configurations on the ESX.
Task
1
Connect the trunk port of Physical switch 1 and Physical switch 2 to two different physical NICs on
the ESX.
2
Create two standard vSwitches for connecting Sensor monitoring ports 1 and 2.
Refer to Create a standard vSwitch for a monitoring port on page 176. Both these switches need
physical adapters. For this scenario, vSwitch0 must be assigned a physical adapter that is
connected to Physical switch 1. Similarly, vSwitch1 must be assigned a physical adapter that is
connected to Physical switch 2.
172
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
Create a switch port group in vSwitch0, which corresponds to the trunk port on Physical switch 1.
a
Log on to the ESX as the root user in VMware vSphere Web Client.
b
In the vSphere Home tab, select Hosts and Clusters.
c
Select the required ESX server and select Manage | Networking | Virtual switches | vSwitch0.
McAfee Network Security Platform 8.1
IPS Administration Guide
173
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
d
Click on Add host networking icon for vSwitch0.
e
For Select target device, select Select an existing standard switch and make sure vSwitch0 is selected.
f
In the Network Label field, enter a name.
For example, enter Physical Client Port.
174
g
In the VLAN ID (Optional) field, select All (4095) because this switch port group corresponds to the
trunk port of a physical switch.
h
Click Next and then Finish.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
i
7
Under Standard switch: vSwitch0 (VM Network), click on the switch port group that you created.
In this example, it is Physical Client Port.
j
With the switch port group selected, click on the Edit Settings icon for the switch port group.
k
In the Edit Settings dialog, select the Security tab and make sure the fields are set with the following
values and click OK.
•
Promiscuous mode — Accept. This is set to accept because traffic related to all the hosts
connected to Physical switch 1 is involved.
•
MAC Address Changes — Reject.
•
Forged Transmits — Accept.
McAfee Network Security Platform 8.1
IPS Administration Guide
175
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
4
Use the previous step to create a similar switch port group in vSwitch1.
This corresponds to the trunk port on Physical switch 2.
5
Assign the switch port group that you created in step 3 to monitoring port 1.
See Specify the switch port groups for monitoring ports on page 191.
6
Assign the switch port group that you created in step 4 to monitoring port 2.
See Specify the switch port groups for monitoring ports on page 191.
Make sure the monitoring port 1 is connected to the corresponding port group (VNSP100-PG-Port1)
on vSwitch0 and the monitoring port 2 is connected to the corresponding port group
(VNSP100-PG-Port2) on vSwitch1. Both these port groups must have their VLAN ID as All (4095).
This is required since the monitoring ports are connected to trunk ports of the physical switches.
7
Verify if you have deployed the Virtual Sensor correctly and whether it is inspecting traffic.
Refer to Verify the deployment on page 199.
Create a standard vSwitch for a monitoring port
Before you begin
If you require external access to VMs connected to this switch, you will be required to
connect an additional physical NIC on the ESX to a physical switch.
You connect monitoring ports to standard vSwitches. When you create a standard vSwitch, ESX
creates a default port group for this vSwitch. Each monitoring port in a Virtual Sensor must be
connected to different port groups.
Task
1
Optionally, connect an additional physical NIC on the ESX to the adjacent physical switch.
In scenario 4, for example, you must connect an additional NIC to the corresponding physical
switch.
2
176
Log on to the ESX as the root user in VMware vSphere Web Client.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
In the vSphere Home tab, select Hosts and Clusters.
4
Select the required ESX server and select Manage | Networking | Virtual switches.
5
Click on the Add host networking icon.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
177
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
6
In the Select connection type section, select the required connection type and click and click Next.
Selecting the connection type depends on your network design and requirements. If the VMs that
will be connected to this switch do not need access outside the ESX then you might select Virtual
Machine Port Group for a Standard Switch. However, for requirements as in scenario 4, it is mandatory to
select Physical Network Adapter. Consider that you now select Virtual Machine Port Group for a Standard Switch.
7
178
For Select target device, select New standard switch, the required number of ports, and then click Next.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
8
7
Based on your network requirements, click on the Add adapters icon and select the corresponding
physical network adapter. Then click Next.
If you select an adapter, make sure that a physical NIC corresponding to the network adapter you
selected is connected to the network.
9
In the Network Label field, enter the required name for the default port group that the wizard creates
for the switch.
You can modify Network Label even later. For easier management, name this as VNSP100-PG-Port1 for
example.
10 In VLAN ID, select All (4095) and select Next.
McAfee Network Security Platform 8.1
IPS Administration Guide
179
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
11 Click Finish.
This vSwitch is now listed under Virtual Switches in the Networking tab.
12 Select the vSwitch that you created, move the mouse over its physical adapter, and click on it.
13 Click on the Edit adapter speed icon.
180
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
14 Verify if the Configured Speed, Duplex is set to Auto negotiate.
For other property values, you can leave them with the default values.
15 Modify the security properties of the vSwitch.
a
Select the vSwitch and click on the Edit settings icon.
b
Select Security and make sure the fields are set to the values mentioned and then click OK.
•
Promiscuous mode — Reject.
•
MAC Address Changes — Reject.
•
Forged Transmits — Accept.
16 Modify the security settings of the default port group.
McAfee Network Security Platform 8.1
IPS Administration Guide
181
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
It is assumed that you will use this port group to connect the monitoring port of a Sensor.
a
Move the mouse over the default port group and click on it.
The switch port group is now selected.
182
b
Click on the Edit settings icon for the switch port group.
c
Click Properties and modify the Network Label if required.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
d
7
Make sure VLAN ID is set to All (4095).
This switch port group must receive all VLAN traffic similar to a trunk port.
e
Click Security, select the Override check box next to Promiscuous Mode and then select Accept from the
drop-down.
This is mandatory for the port group that you will use for any Sensor monitoring port.
17 Create a new port group for the other VMs in this vSwitch.
For example, in scenario 2, this is the port group that you will use for the 10.10.10.16 server.
Skip this step for scenario 4.
a
Select the corresponding vSwitch and click on the Add host networking icon.
McAfee Network Security Platform 8.1
IPS Administration Guide
183
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
b
In the Select connection type step, select Virtual Machine Port Group for a Standard Switch and then click Next.
c
In the Select target device step, select Select an existing standard switch and make sure the vSwitch that
you created is selected. Then click Next.
d
In the Network Label field, enter the required name for the default port group that the wizard
creates for the switch.
You can modify Network Label later. For easier management, you can name it as Server Port.
e
In the VLAN ID (Optional) field, you can specify the required VLAN. For scenario 1, for example,
select None (0) and click Next and then Finish.
None (0) means that the traffic is not tagged with a VLAN.
184
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
f
7
Move the mouse over the switch port group and click on it.
The switch port group is now selected.
g
Click on the Edit settings icon for the switch port group.
h
In the Security tab, make sure the fields are set with the following values and click OK.
•
Promiscuous mode — Reject.
•
MAC Address Changes — Reject.
•
Forged Transmits — Accept.
18 Click OK to close the Edit settings dialog.
McAfee Network Security Platform 8.1
IPS Administration Guide
185
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
Modify an existing standard vSwitch for a monitoring port
If you plan to connect a monitoring port to an existing vSwitch, you might have to modify some of the
configuration. For example, in scenario 2, you need to modify virtual switch 1 to connect it to
monitoring port 1.
Task
1
Log on to the ESX as the root user in VMware vSphere Web Client.
2
In the vSphere Home tab, select Hosts and Clusters.
If the page takes time to render, click on the page-refresh icon at the top.
186
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
3
Select the required ESX server and select Manage | Networking | Virtual switches.
4
Select the required vSwitch and click on its Edit settings icon.
5
Select Security and make sure the fields are set to the values mentioned and then click OK.
6
•
Promiscuous mode — Reject.
•
MAC Address Changes — Reject.
•
Forged Transmits — Accept.
7
Modify the port group that you are using for the VMs in this switch.
McAfee Network Security Platform 8.1
IPS Administration Guide
187
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
For example, in scenario 2, this is the port group that you use for the 10.10.10.15 client.
This step might be relevant only for scenario 2.
a
Move the mouse over the required port group and click on it.
The switch port group is now selected.
b
Click on the Edit settings icon for the switch port group.
c
Click Properties and modify the Network Label if required.
For example, change it to Client Port.
d
188
In the VLAN ID (Optional) field, you can specify the required VLAN. For the scenarios in this
section, select None (0).
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
e
7
7
Click Security and make sure the fields are set with the following values and click OK.
•
Promiscuous mode — Reject.
•
MAC Address Changes — Reject.
•
Forged Transmits — Accept.
Create a port group to connect the monitoring port of a Sensor.
a
Select the corresponding vSwitch and click on the Add host networking icon.
b
In the Select connection type step, select Virtual Machine Port Group for a Standard Switch and then click Next.
McAfee Network Security Platform 8.1
IPS Administration Guide
189
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
c
In the Select target device step, select Select an existing standard switch and make sure the vSwitch that
you created is selected. Then click Next.
d
In the Network Label field, enter the required name
For example, enter VNSP Client Port.
e
Make sure VLAN ID is set to All (4095), click Next and then Finish.
f
Move the mouse over the switch port group and click on it.
The switch port group is now selected.
190
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
g
Click on the Edit settings icon for the switch port group.
h
In the Security tab, select Override next to Promiscuous mode and then select Accept from the
drop-down. Click OK when done.
7
This is mandatory for the port group that you will use for any Sensor monitoring port.
Specify the switch port groups for monitoring ports
When you install the Virtual Sensor, you select the switch port group for the required Sensor ports. No
two port must be connected to the same switch port group to prevent loopback. As a precaution, the
monitoring and response ports are disconnected by default.
As a good practice, assess the vSwitches and the switch port groups that you would require. Then you
can create them in your ESX before you begin installing the Virtual Sensor. You can also create the
dummy switch port groups for the ports that you do not plan to deploy.
McAfee Network Security Platform 8.1
IPS Administration Guide
191
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
The first two network adapters correspond to the management port and the response port
respectively. The remaining adapters correspond to the monitoring ports. The following graphic shows
the mapping between network adapters and the Sensor ports for IPS-VM100.
Figure 7-8 Network adapter to Sensor port mapping
The left side is the Virtual Machine Properties dialog that you can access in the vSphere client for a
Virtual Sensor. To access the Virtual Machine Properties dialog, select the Virtual Sensor in the
vSphere client and then select Edit virtual machine settings. The right side of the graphic shows the Physical
Ports page in the Manager for a Virtual Sensor.
In case of IPS-VM600, network adapters 3 through 8 correspond to the monitoring ports in the same
order. Network adapters 1 and 2 correspond to the management port and the response port
respectively.
Task
1
192
Log on to the ESX as the root user in VMware vSphere Web Client.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
2
In the vSphere Home tab, select Hosts and Clusters.
3
Under the corresponding ESX, select the required Virtual Sensor.
7
You can view the network adapters corresponding to the Sensor ports in the VM Hardware section.
The current status of these adapters is also displayed.
4
Click Edit Settings in the VM Hardware section.
McAfee Network Security Platform 8.1
IPS Administration Guide
193
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
5
In the Edit Settings dialog, select Connected check box for the required network adapters (Sensor ports)
and click OK.
In the VM Hardware section, you can verify that these network adapters are now connected.
Deploying Virtual Sensor monitoring ports in inline fail-open mode
Before you begin
Before you deploy monitoring ports in inline fail-open mode, make sure the Sensor is
functioning as expected with the same ports in inline fail-closed mode.
If a Virtual Sensor receives traffic from a physical network device, then you can deploy an inline pair in
inline fail-open mode. Consider a scenario, wherein the Virtual Sensor inspects traffic between virtual
machines as shown (scenario 4).
194
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
The monitoring port pair 1-2 is inline between physical switches 1 and 2. By default, inline monitoring
ports of a Virtual Sensor are in the fail-closed mode. The network between the client and the server is
broken under any of the following conditions:
•
Link failure in either port 1 or 2.
•
Power or application failure in the Virtual Sensor.
•
Either vSwitch0 or vSwitch1 is down.
•
Link failure in either vmnic0 or vmnic1.
•
The ESX server is down.
To mitigate the risk of network breakdown due to the above-mentioned conditions, you can deploy the
monitoring port 1-2 in fail-open mode. Fail-open operation for the monitoring ports of a Virtual Sensor,
require the use of an external copper bypass switch.
•
Only McAfee-certified 10/100/1000 external Copper active fail-open bypass kits are supported.
•
Installing the active fail-open bypass kit involves a brief network downtime.
McAfee Network Security Platform 8.1
IPS Administration Guide
195
7
Virtual IPS Sensor deployment
Deploying Virtual Sensors
Task
1
Install the 10/100/1000 external Copper active fail-open bypass kit and power it on (with dual
power sources).
Refer to 10/100/1000 Copper Active Fail-open Bypass Kit Guide for information.
196
2
Disconnect the trunk port of Physical switch 1 from vmnic0, and connect the trunk port to the port
marked A in the bypass kit.
3
Similarly, disconnect the trunk port of Physical switch 2 from vmnic1, and connect the trunk port to
the port marked B in the bypass kit.
4
Connect the port marked 1 to vmnic0 and the port marked 2 to vmnic1.
5
In the Manager, set the port in inline fail-open active mode.
a
Click the Devices tab.
b
Select the domain from the Domain drop-down list.
c
In the left pane, click the Devices tab.
d
Select the device from the Device drop-down list.
e
Select Setup | Physical Ports.
f
Double-click on the required port and select In-line Fail-open Active in the Mode field.
g
Confirm and then click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
Virtual IPS Sensor deployment
Deploying Virtual Sensors
7
•
In the Sensor CLI, run the show intfport <port number> command and verify that Fail-Open
Switch shows PRESENT and Fail-Open Port shows INLINE.
•
When the Sensor is operating, the switch is on and routes all traffic directly through the
Virtual Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
197
7
198
Virtual IPS Sensor deployment
Deploying Virtual Sensors
•
When the Sensor fails, the switch automatically shifts the Virtual Sensor to a bypass state:
in-line traffic continues to flow through the network link, but is no longer routed through the
Sensor.
•
When a monitoring port goes down, its status in the Manager is shown as unknown. A
critical-fault message is also generated. This message is cleared when the monitoring port
pair is back inline.
McAfee Network Security Platform 8.1
IPS Administration Guide
7
Virtual IPS Sensor deployment
Generate the Virtual IPS Sensor License Compliance report
•
If the monitoring port is down or if the Sensor goes into layer 2 bypass mode, the fail-open
bypass kit turns on and the traffic bypasses the Sensor. If you run the show intfport <port
number> command, the Fail-Open Port field displays BYPASS.
•
If the Sensor layer 2 bypass mode, the Fail-Open Port field, displays LAYER2_BYPASS.
•
Once the Sensor resumes normal operation, the bypass switch returns to the off state, again
enabling in-line monitoring.
For the details of how the external Copper active fail-open bypass kit works, see the
10/100/1000 Copper Active Fail-open Bypass Kit Guide.
6
You can also configure the bypass switch to operate in tap mode.
•
See 10/100/1000 Copper Active Fail-open Bypass Kit Guide for information.
•
There is no specific configuration in the Physical Ports page in the Manager for tap mode. The
configuration is only in the bypass switch.
•
When the bypass switch is in tap mode, and you run show intfport <port number> command,
the Fail-Open Port field displays TAP.
Verify the deployment
You can use the following information to verify if you have deployed the Virtual Sensor correctly and if
it is inspecting traffic.
Task
1
Make sure the Sensor management port and the Manager server and reachable to each other.
2
On the Sensor CLI, use the status and show commands to see if trust is established, the channels
are up, and if the Sensor is in good health.
3
On the Manager Dashboard, check the System Health monitor to verify if the Sensor is active.
4
In the Manager, select Devices | <Domain name> | Devices | <Device name> | Setup | Physical Ports and check if
the monitoring ports and up.
5
Verify if the client and server are reachable from one another.
6
Send a sample attack from the client to the server, for example root.exe, and check if an alert is
raised in the Real-Time Threat Analyzer with the correct details.
7
After you deploy a Virtual Sensor, the process of configuring and managing it is similar to that of a
physical Sensor. Therefore, refer to the corresponding section for information. For example, the
procedures related to virtualization of monitoring ports is similar to that of physical ports.
Therefore, refer to How to understand virtualization for information on how to create sub-interfaces
out of the monitoring ports of a Virtual Sensor.
Generate the Virtual IPS Sensor License Compliance report
If you want to generate a report on your compliance with respect to Virtual Sensor licenses, you
generate the Virtual IPS Sensor License Compliance report. This report summarizes the current Virtual
Sensor license compliance. In addition, it also lists the virtual Sensors currently managed by the
Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
199
7
Virtual IPS Sensor deployment
Generate the Virtual IPS Sensor License Compliance report
Task
1
In the Manager select Manage | admin domain | Reporting | Configuration Reports | Virtual IPS Sensor License
Compliance.
2
Select the required option from the Output Format list and click Submit.
Figure 7-9 Virtual IPS Sensor License Compliance report
200
Option
Description
License Status
Indicates the current compliance status.
Total Number of Virtual IPS Sensors
Allowed
This number quantifies the number of Virtual Sensors that can be
under this Manager.
Total Number of Virtual IPS Sensors
Managed
Indicates the number of Virtual Sensors currently managed by the
Manager.
Report Generation Time
Time when you generated the report.
License Key
Displays the license key of the license file.
Generated
The date when the license file was generated.
Customer
The customer for whom the license file was generated.
Grant ID
The McAfee Grant ID of the corresponding customer.
Allowed Virtual IPS Sensors
This corresponds to the number of licenses per license file.
Imported Time
The timestamp of when the license file was imported into the
Manager.
Imported By
The user who imported the license file.
Comment
The user comment that was entered in the Virtual IPS Sensor Licenses
page.
Virtual IPS Sensor Name
Names of the Virtual IPS Sensors managed under the admin
domain.
Virtual IPS Sensor Model
The model of the Virtual IPS Sensors.
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
You should already be familiar with the terms Virtual IDS (VIDS), Virtual IPS (VIPS), and
sub-interfaces.
These terms all refer to a concept more generally known as virtualization. The goal of virtualization is
to provide scanning granularity. Virtualization enables an administrator to apply different policies to
different groups of traffic flowing through a single Sensor port or port pair.
The terms VIDS and VIPS reinforce the idea that virtualization allows you to tailor a single Sensor
solution as if it was a multiple-Sensor solution. McAfee® Network Security Platform user interface uses
the term sub-interface, however, and this term better describes the process by which virtualization is
implemented. For this reason, we will use the term sub-interface here.
The easiest way to cover the implementation and benefits of virtualization is to start with a non-virtual
Sensor implementation and work our way to multiple sub-interfaces.
Consider the I-2700 model Sensor: It has eight physical monitoring ports of which six are 10/100 Fast
Ethernet ports and two are Gigabit Ethernet.
All eight ports inherit and use the policy applied to the Sensor. You can apply a unique policy to each
port, and many people do. This notion of hierarchy is important to remember at the outset of the
discussion because, as you will soon see, sub-interfaces also take advantage of the power of the
hierarchical Network Security Platform management design.
This chapter discusses the concepts and procedures related to virtualization of Sensor monitoring ports.
These virtualization concepts and procedures explained in this chapter apply to both physical and Virtual
IPS Sensors. However, for information on how to deploy Virtual IPS Sensors, see Virtual IPS Sensor
deployment .
Contents
Network scenario without virtualization
Virtual IPS
Port versus interface
Network scenario with virtualization
Interface types
How policies are applied
Common use of VLAN, bridge VLAN, and CIDR interfaces
Interface, VLAN, and CIDR limits
Network scenario without virtualization
Imagine a network on which Windows and Linux hosts are interspersed. The best approach here is to
apply a policy that includes attacks for both Windows and Linux hosts on all the ports through which
their traffic will flow.
McAfee Network Security Platform 8.1
IPS Administration Guide
201
8
How to understand virtualization
Virtual IPS
If this network happens to be controlled in such a way that the traffic from all the 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 Sensor 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.
When you consider that many IDS and IPS offerings only allow for a single policy per Sensor, the
option to apply a unique policy to each port is that much more impressive. But what happens if a
Sensor doesn't have enough physical ports to cover the different ways in which traffic may be
controlled on a given network? Or more realistically, what happens if the Sensor is placed at an
aggregation point on the network, such as on a trunked uplink, or an administrator wants a unique
policy applied to a single host or two. This is when virtualization becomes relevant.
Virtual IPS
Most sensor-based IPS 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. Sensor appliances have
multiple ports coupled with multiple policy application options. Thus, Network Security Platform offers
Virtual IDS(VIDS) and Virtual IPS (VIPS).
To make use of virtualization, consider that a Sensor is made of the following resources:
•
Sensor itself as a whole
•
Sensor monitoring ports
•
Interfaces
•
Sub-interfaces
The VIPS feature enables you to configure multiple policies for multiple unique environments and
traffic directions all monitored with a single 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 M-1450 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. In this case,
each monitoring port of the Sensor is an interface. The other option is to segment each monitoring
port by multiple VLAN tags or CIDR addresses, each customized with its own security policy. In this
case, each monitoring port is segmented into virtual sub-interfaces.
Sensors
A security 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 IPS policy called Custom1. You apply it to interfaces 1B, 2A, and 4B on a
single I-2700 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
202
McAfee Network Security Platform 8.1
IPS Administration Guide
How to understand virtualization
Virtual IPS
8
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 Network Security
Platform 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.
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 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 a Windows Server
IPSpolicy and apply it to the Payroll interface and a Solaris Server IPSpolicy 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 Network Security Platform user interface uses the
term sub-interface, and this term better describes the process by which virtualization is implemented.
McAfee Network Security Platform 8.1
IPS Administration Guide
203
8
How to understand virtualization
Virtual IPS
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. 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.
Figure 8-2 Sub-interfaces
In the above figure, 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.
Policy inheritance
A security 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.
204
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Port versus interface
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 (for example, admin domain level) once they have been applied at a
lower level has no effect on the lower levels (for example, 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.
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.
Port versus interface
Networking professionals often interchange the terms port and interface, and we have purposely
done so to this point. In the Network Security Platform 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 ports.
A simple 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 two physical ports as a single logical
interface.
A sub-interface is a further abstraction of an interface. It allows an administrator to apply different
scanning policies to different types of traffic flowing through the same interface.
Network scenario with virtualization
Assume there is a single uplink to and from the Internet for all internal hosts, and that this uplink
sends traffic through a Sensor running inline. That is, the Sensor does indeed reside at an aggregation
point for this network.
McAfee Network Security Platform 8.1
IPS Administration Guide
205
8
How to understand virtualization
Interface types
If the Windows and Linux hosts are scattered across the network, creating a sub-interface will be of
little value; the best approach here is to again use a single policy that will account for both types of
traffic.
If these hosts have been given different ranges of IP addresses or reside on different VLANs, however,
you can create a sub-interface for each block of addresses or VLAN, and achieve the same result
across a single interface as you did previously when each group of traffic traversed a unique port.
Additionally, if there is a requirement to apply a unique policy to a specific host, you can do so by
creating a sub-interface to represent that one host. For example, if your DMZ is comprised entirely of
Windows servers, with the exception of a single Solaris server, it makes good sense to apply a
Windows-specific policy to the interface and a Solaris-specific policy to a sub-interface representing
that one host.
It is also worth noting that each interface and sub-interface maintains a unique denial-of-service
(DoS) profile. So 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.
This may appear similar to the option to create unique DoS IDs at the interface level, and it is. The
difference is that interface-level DoS IDs are limited to a single layer of CIDR addressing, whereas DoS
IDs at the sub-interface level allow you to create DoS profiles by VLAN ID as well as have two layers
of CIDR addressing. For example, you can create a DoS profile for an entire CIDR range at the
interface level, and then create a unique DoS profile for an individual host on that same network at
the sub-interface level.
Interface types
Valid interface types include:
206
•
Dedicated
•
VLAN
•
Bridge VLAN
•
CIDR
McAfee Network Security Platform 8.1
IPS Administration Guide
How to understand virtualization
Interface types
8
Dedicated interfaces
The Interface Type option in the Edit window has the default Dedicated interface.
Figure 8-3 Interface Type option
When the default interface supports a sub-interfaces, Virtualization is effectively disabled.
VLAN interfaces
When you choose an interface type of VLAN, you instruct the Sensor to apply policies according to
VLAN tags.
Background
Imagine you have two hosts residing on the same VLAN and connected to two different switches, but
you want them to communicate as if they were directly connected to the same switch, this includes
sharing Layer 2 multicasts and broadcasts. The way to achieve this goal is to set up a trunk between
the two switches.
When you enable trunking on both switches, they will pass extra information in each frame to identify
the VLAN to which that frame belongs.
As a frame travels across a trunk, the receiving switch checks the VLAN ID and copies the frame to
local ports in the same VLAN as if that frame had originated locally.
A switch that meets the industry-standard, IEEE 802.1Q specification for trunking will include an
additional 32 bits in each frame, of which 12 of the bits are used to indicate the VLAN ID for that
frame. Valid VLAN ID values are therefore between 0 and 4095 (2^12).
The actual supported VLAN ID values will vary by switch implementation. For example, VLAN 0 is
generally not used, VLAN 1 is the default VLAN is used for management on Cisco switches, and many
switches do not support all the way up to VLAN ID 4095 unless you use an enhanced version of
software. Network Security Platform will accept values between 1 and 4095.
Network Security Platform will initially accept a value of 0 in the GUI, but then discard it. For example, if
you enter a range of 0 - 2, Network Security Platform will accept it, but only include VLAN IDs 1 and 2
in its configuration.
If you send trunked traffic across a device that does not specifically support trunking, that device will
typically discard tagged frames as bad (too large) and communication will fail.
Network Security Platform supports (passes and scans) frames meeting the 802.1Q standard. It does
not, however, support Cisco's proprietary, legacy Inter-Switch Link (ISL) protocol. ISL traffic sent
through a Sensor will be forwarded and would not be dropped.
McAfee Network Security Platform 8.1
IPS Administration Guide
207
8
How to understand virtualization
Interface types
Defining VLAN interfaces definition
After you have configured an interface to be of type VLAN, the next step is to edit it and associate
VLAN IDs with it. You will want to define here all the VLANs whose traffic you anticipate will traverse
this interface.
The expectation is that you will see traffic from multiple VLANs. (If not, it would be simpler to leave
the interface as type Dedicated and apply a single policy, or consider a CIDR sub-interface instead).
You can specify VLAN values by Range from or by IDs.
Figure 8-4 Edit VLAN Interface window
VLAN sub-interfaces definition
The next step is to allocate one or more of those VLANs to a sub-interface to further refine the
scanning process.
In the figure Adding a sub-interface, we are adding a sub-interface called WindowsServers, assigning it the
Default Inline IPS policy, and allocating VLANs 2 and 5 to it:
Figure 8-5 Sub-Interface Details window
We highly recommend you give the sub-interface a name that indicates its contents. The name could
have been as obvious as VLANS_1_2. It is more common, however, to name the sub-interface after
the user community or hosts it protects, for example, Accounting_VLANs or, as is the case here,
WindowsServers.
When we now look back at the details of the interface, a few things have changed:
The resource tree in the figure Interface details now includes an icon representing the new sub-interface.
VLANs 1and 10 are shown in the Details window to be associated with the new sub-interface (and
therefore its policy).
208
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Interface types
The details of the final configuration are as follows:
•
Traffic with a VLAN tag ID of 1 or 5 will have the Default Inline IPS policy applied to it.
•
Traffic with a VLAN tag ID of 2 will have the Default IDS policy applied to it.
We could of course create another sub-interface for Linux servers and allocate VLAN 7-9 to it, for
example. At that point, all VLANs defined on the VLAN 7-9 interface would be allocated to
sub-interfaces.
If we subsequently wanted to allocate yet another VLAN to a sub-interface, we would first have to
de-allocate an existing VLAN ID from an existing sub-interface or add another VLAN ID to the 2A-2B
interface.
Bridge VLAN interfaces
A Bridge VLAN interface is similar to that of a VLAN interface except that post traffic inspection, the
Sensor changes the VLAN tag of the traffic to the one that you specify.
Thus the Sensor bridges the traffic between these two VLANs. This feature can enable effective
utilization of the IPS capacity of your Sensors.
This is applicable only for M-8000, M-6050, M-4050, and M-3050 Sensors deployed inline.
McAfee Network Security Platform 8.1
IPS Administration Guide
209
8
How to understand virtualization
Interface types
Background
Consider a typical network where many access switches connect to a few distribution switches as
shown partly in the figure below. To monitor inter-VLAN traffic, you can place a Sensor inline for every
trunk link between the access switches and the distribution switch. However, this would mean
deploying a large number of Sensor port pairs (one for every trunk link between the access and
distribution switches) and hence may require a large number of Sensors.
Figure 8-6 A simple scenario without VLAN bridging
210
McAfee Network Security Platform 8.1
IPS Administration Guide
How to understand virtualization
Interface types
8
An alternative and cost-effective solution for this scenario would be to monitor the aggregated traffic
at the distribution switch as shown in the figure below.
Figure 8-7 A simple scenario with VLAN bridging
With this method, the same volume of traffic can be monitored with less number of Sensors provided
the aggregate traffic at the Distribution switch monitored by the Sensor does not exceed the Sensor
throughput. This solution requires the following: the VLANs on the access switches and the distribution
switch must be configured in such a way that all traffic that is to be subjected to IPS is forwarded to
the Sensor before being switched or routed. Then the Sensor inspects and bridges the traffic using
VLAN Bridging. Effectively, traffic from the access switches is switched or routed only after VLAN
bridging by the Sensor.
Additionally, if you have multiple Sensors (or Sensor interfaces) connected to the distribution switch,
then you can configure Ether Channel Load Balancing (ECLB) on the switch so that the traffic is split
across the Sensors or Sensor ports for optimal utilization of your IPS infrastructure. This section does
not have information on how to configure your switches for ECLB. Refer to the documentation provided
with your switch.
McAfee Network Security Platform 8.1
IPS Administration Guide
211
8
How to understand virtualization
Interface types
A simple VLAN bridging scenario
Consider this scenario to understand the advantages of VLAN Bridging:
Figure 8-8 VLAN bridging scenario
212
1
Host 10.1.1.10 in VLAN 100 tries to communicate with a host 10.1.2.10 in VLAN 200.
2
Access Switch 01 tags the packet with VLAN 100 and forwards it to the Distribution Switch. The
Distribution Switch is an L3 switch, which has trunk links to the Sensor.
3
In the distribution switch, only the ports connected to 1A of the Sensor and Access Switch 01 are
configured for VLAN 100. No other ports are configured for 100. This is a very critical configuration
for enforcing IPS. When the Distribution Switch receives VLAN 100 traffic, the only network path
available is to the Sensor.
4
In the distribution switch, only the ports connected to 1B are configured for VLAN 101.
5
The Sensor is configured to bridge VLANs. This is done by specifying the VLANs to be bridged as a
pair at the interface level.
6
For this scenario, let us assume that you have configured VLANs 100 and 101 as a VLAN pair.
Assuming the traffic is clean, the Sensor changes the VLAN tag to 101 and forwards it to the
Distribution Switch through the corresponding peer port. Conversely, traffic tagged 101 is changed
to tag 100 and sent through the corresponding peer port. Thus, the Sensor bridges VLANs 100 and
101.
7
The Distribution Switch receives the traffic tagged 101. Based on ARP, ARP replies, and the
destination subnet, the switch forwards the traffic to the appropriate port so that it reaches host
10.1.2.10.
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Interface types
Note the following before you configure VLAN Bridging:
•
You can configure VLAN Bridging only on M-series Sensors deployed in in-line mode.
•
Note that the distribution switch configuration has to keep the traffic separation of inbound/
outbound on one Sensor's two links: the switch must restrict traffic from the outside net VLAN to
only one link, and the inside net VLAN to only the other link. This switch configuration should be
consistent with the Sensor's port designations of inbound/outbound.
•
If the traffic has a VLAN tag that is not configured on the Sensor, then post-IPS the traffic comes
out from the Sensor to the switch with the same VLAN tag. Because both 1A and 1B are connected
to the same switch, it will detect a loop and attempt to bring down the ports. For this reason, it is
important that you disable Spanning Tree Protocol on the switch.
•
VLAN bridging will not work when Sensor enters L2 mode or when Sensor ports fail-open. This may
result in traffic drop.
Define bridge VLAN interfaces
Configuring a Sensor to act as a VLAN Bridge.
Task
1
Defining Bridge VLAN Interfaces: You need to change the Interface Type to Bridge VLAN.
a
Go to Devices | <Admin Domain Name> | Devices | <Device_Name> | IPS Interfaces | <Interface_Name> | Protection
Profile.
The Interface Detail page displays.
b
In the Properties page, change the Interface Type to Bridge VLAN and click OK to confirm.
When you change the Interface Type, the configurations relevant to the earlier Interface Type is
lost. For example, if the Interface was of type VLAN earlier with VLAN ID list configured, then
this list is lost when you change this interface to Bridge VLAN.
2
Specifying the VLAN pairs: At the Interface level, you need to specify the VLANs that are to be
bridged as a pair. For example, if you want to bridge VLANs 10 and 11, then you need to specify
them as a pair. Then, the Sensor tags VLAN 10 traffic as VLAN 11 before forwarding it through the
peer port. Similarly, it tags VLAN 11 traffic as VLAN 10.
You can define all the VLANs that you want the Sensor to bridge now. Then, you can assign all or
part to the Sub-Interfaces.
For each VLAN pair that you want to specify:
a
From the Properties page, click Edit.
The Edit Bridge VLAN Interface appears.
McAfee Network Security Platform 8.1
IPS Administration Guide
213
8
How to understand virtualization
Interface types
b
Enter the VLAN ID and its peer in the corresponding fields and click Add.
c
Repeat the steps a and b to add more VLAN pairs.
To delete a VLAN pair, select it in the Properties page and click Delete.
At a given point in time, up to 127 pairs of VLANs can be defined per VIDS. When you reach 127
VLAN pairs at the interface level, you can assign some or all of them to a Sub-Interface to be
able to define more at the interface level.
The VLANs should be unique within an Interface. For example, you cannot configure 20-21 and
22-21 as two VLAN pairs for one Interface.
The VLAN pairs are symmetric; the VLANs are mapped with their peer IDs regardless of the
Sensor port in which they are seen. The switch port connecting to the Sensor port must be
configured to receive the corresponding VLAN traffic.
3
Updating the Sensor: After you define the Bridge VLAN interface, you must update the Sensor
about this configuration change. See McAfee Network Security Platform IPS Administration Guide.
Define bridge VLAN sub- interfaces
You can allocate one or more VLAN pairs defined at the interface to a sub-interface to further refine
the process.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device_Name> | IPS Interfaces | <Interface_Name> |
Sub-Interfaces.
The sub-interface list appears.
2
To allocate VLAN pairs to an existing sub-interface, click Edit; else click New.
3
If you are creating the sub-interface, specify the sub-interface name and policy to be applied.
4
Select the required VLAN pairs from the Available VLAN ID list and move them to the Allocated VLAN ID list.
The Available VLAN ID list contains the VLAN pairs defined at the interface.
5
For the configuration shown above, if the Sensor sees traffic tagged with VLANs 10, 11, 12, or 13,
it applies the corresponding policy of Finance_VLAN sub-interface. After applying this policy, if the
Sensor finds traffic to be clean, it changes the VLAN tag to that of the peer VLAN and forwards it
through the peer port. For example, if the traffic is tagged 12 and seen at 1A, then tags it as VLAN
13 and forwards it through 1B.
If the traffic seen at an interface is tagged with a VLAN defined at the Interface level but not
allocated to a Sub-Interface, then the Sensor applies the policy specified for the Interface and also
changes the VLAN tag to that of its peer.
6
Updating the Sensor: After you allocate VLAN pairs to sub-interfaces, you must update the Sensor
about this configuration change. See Updating the configuration of all Sensors, McAfee Network
Security Platform IPS Administration Guide.
VLAN bridging details
VLAN Bridging details in the Threat Analyzer
214
McAfee Network Security Platform 8.1
IPS Administration Guide
How to understand virtualization
Interface types
8
For alerts generated from Interfaces configured for VLAN Bridging, the VLAN from which the attack
originated is included. For example, a VLAN ID of 11 indicates that the source host is in VLAN 11. For
information on Threat Analyzer, see McAfee Network Security Platform Manager Administration Guide.
Figure 8-9 VLAN bridging details in Threat Analyzer
VLAN Bridging details in reports
Selecting the Port Configuration and Interface Configuration in the Sensor Configuration Report,
displays the Bridge VLAN type interfaces and the corresponding VLAN pairs. For information on
reports, see McAfee Network Security Platform Manager Administration Guide.
VLAN bridging for Sensors in fail-over mode
This section explains a sample scenario in which Sensors in fail-over mode are configured for VLAN
Bridging.
Figure 8-10 Sensors in fail-over mode
McAfee Network Security Platform 8.1
IPS Administration Guide
215
8
How to understand virtualization
Interface types
The network design in the diagram above is as follows:
•
This scenario represents an active/standby network path.
•
Client 10.1.1.20 is in VLAN 100 and the server 11.1.1.20 is in VLAN 200.
•
The client is connected to an access switch AS 1 and the server is connected to the access switch
AS 2.
•
The access switches, AS1 and AS2 are connected to two L3 switches (DS1 and DS2) for
redundancy.
•
Spanning Tree Protocol is disabled in both DS1 and DS2.
•
DS1 is connected to Sensor 01 and DS 2 is connected to Sensor 02. These Sensors are in fail-over
mode.
•
Sensor ports 1A and 1B are configured to bridge VLANs 100 and 150.
•
In DS 1 and DS 2 only the ports connecting to 1A and AS 1 are configured for VLAN 100.
•
Only the switch ports connected to port 1B are configured for VLAN 150.
•
The ports of DS1 and DS2 connecting to 1B are configured as one Hot Standby Routing Protocol
(HSRP) group. This provides an active/standby network path.
•
The ports of DS1 and DS2 that connect to AS2 are configured as one HSRP group to provide the
active/standby network path for the response traffic.
•
It is critical that the HSRP Hello multicasts from HSRP group members reach all the participating
HSRP group members to trigger a HSRP switchover.
The flow of traffic when the client tries to access the server is as follows:
•
Traffic from the client is tagged VLAN 100 by AS1 and then sent to either DS1 or DS2 based on
which path is active. Let us assume that currently DS1 is active and DS2 is in standby.
•
From DS1, the only path available for the VLAN 100 traffic is it to port 1A of Sensor 01.
•
If the traffic is clean, the Sensor changes the VLAN tag to 150 and sends it out through 1B.
•
DS1 does inter-VLAN routing accordingly and the traffic reaches the server through AS2.
•
If Sensor 01 is down, then HSRP failover is triggered and DS2 becomes the active path. As a result,
IPS and VLAN bridging are performed by Sensor02. All the flows that were processed by Sensor01
are intact since Sensor02 has the updated state information for all those flows and it takes over
seamlessly.
CIDR interfaces
When you choose an interface type of CIDR, you are instructing the Sensor to apply policies according
to the IP address of one or more hosts.
Background
The strategy for classless inter-domain routing (CIDR) was originally submitted to the networking
community as RFC 1519 in 1993.
RFC 1519 aimed to address two of the principal networking problems of its day:
216
•
The exhaustion of the class B network address space.
•
The unmanageable growth of routing tables in Internet routers.
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Interface types
In so many words, CIDR introduced the concept of "subnetting."
Before RFC 1519, networks were "classful." That is, an explicit network mask was not used to
determine the quantity of hosts a network could maintain. Instead, a class was determined based on
the value of the first octet in the IP address.
Class
Value of First Octet
Assumed Network Mask
A
1 - 126
255.0.0.0
B
128 - 191
255.255.0.0
C
192 - 223
255.255.255.0
For example, an IP address of 32.x.x.x was assumed to have an 24-bit network mask (class A), an
address of 155.x.x.x was assumed to have a 16-bit mask (class B), and an address of 210.x.x.x was
assumed to have a 8-bit mask (class C).
According to RFC 1519, the fundamental cause of the exhaustion of the class B network address space
was the lack of an appropriate class for mid-sized organizations. Specifically, a class C network allows
for a maximum of 254 usable hosts (2^8) - 2, which is typically too small, whereas, a class B network
provides 65534 usable hosts (2^16) - 2, which is overkill in most cases.
You subtract 2 from the quantity of usable hosts to account for the network address and the broadcast
address for each segment.
The overwhelming growth of routing tables is also a product of this shortcoming. Imagine your
network has 1000 hosts. It would not be in the interest of your ISP to allocate your company a full
class B network, yet a class C network would not suffice. Instead, the ISP would likely allocate you
four class C networks. Unfortunately, the ISP would then have to include a new route for each of those
four networks in its routing tables and propagate them across the Internet.
In this case, four routes would be added to the Internet routing space when a single route could have
ideally achieved the same end.
CIDR deprecates the notion of network class and introduces the requirement that all networks and
hosts be represented by a combination of IP address and explicit network mask. In this way, CIDR
resolves both the aforementioned problems. Specifically, CIDR allows for:
•
The straightforward division of class B networks into blocks of class C networks.
•
Aggregation of those blocks into a single Internet route.
CIDR arithmetic
When you calculate subnets, it is helpful to remember that:
•
There is a finite amount of bits with which to work (32 bits, assuming IPv4).
•
Bits can either represent a network or a host, but not both. So each time a bit is allocated to one,
that implicitly means it has been de-allocated from the other.
The calculations are in binary, so each time you allocate an additional bit to networks, for example,
you double the quantity of available networks, but cut the quantity of hosts per network in half. (If
you instead allocate an additional bit to hosts per network, the opposite is true.)
Consider a traditional class B network of 155.49.0.0. Its traditional network mask is 255.255.0.0. That
is, out of the 32 bits available for a network mask, 16 of those bits are representing networks and 16
are representing hosts per network. This leaves us with 65534 usable hosts per network (2^16) - 2.
McAfee Network Security Platform 8.1
IPS Administration Guide
217
8
How to understand virtualization
Interface types
An ISP will likely reallocate this network with a longer network mask (more bits allocated to networks)
to get a greater quantity of blocks of networks from that range. The ISP might allocate the 155.49.0.0
range using a 21-bit mask (255.255.248.0) instead, for example. In doing so, the ISP can find a
happy medium between traditional class B and class C networks.
In the specific case of a 21-bit network mask, the ISP can reallocate the 155.49.0.0 range in 32 blocks
of (8) class C networks and use a single route to represent each block. How is that achieved?
If we do not subnet the 155.49.0.0 network at all, we are left with a single network containing 2^16 2 or 65,534 hosts.
If we now allocate another bit to the networks (17 bits) and therefore take one away from the hosts
(15), the quantity of subnets doubles to 2, and the quantity of hosts per subnet is cut to 2^15 - 2 or
32,766.
Again, each time we add a bit to the network mask, we double the quantity of subnets available, but
split the quantity of hosts per network in (almost) half.
If we follow the same arithmetic for our 21-bit network mask, that yields 32 subnets. It also leaves 11
bits for the hosts or 2046 (2^11 - 2) hosts per subnet.
Calculation of the quantity of subnet blocks
To quickly determine the quantity of subnets a given mask will yield, you subtract the number of bits
in the traditional, "classful" mask from the mask you aim to use, and then use the difference to find
the binary exponent.
In our example, a traditional class B network mask uses 16 bits, whereas we aim to use a 21-bit
mask. So the equation is:
21 - 16 = 5
The binary exponent is then 2^5 or 32 available subnets.
Calculation of the quantity of networks per block
To determine the quantity of class C networks each of those 32 subnets will contain, you subtract the
number of bits you aim to use from the traditional, "classful" mask, and then use the difference to find
the binary exponent.
This time, we are interested in (blocks of) traditional class C networks, which each use a mask of 24
bits, and we still aim to use a 21-bit mask. So the equation is:
24 - 21 = 3
The binary exponent is 2^3 or 8 class C subnets per block.
Sample class C blocks
The following are the first three class C network blocks resulting from the combination of the
155.49.0.0 network and a 21-bit mask, as well as the corresponding Internet route required for each
block
BLOCK #1
Allocated customer class C networks:
155.49.0.0 / 24
155.49.1.0 / 24
155.49.2.0 / 24
218
McAfee Network Security Platform 8.1
IPS Administration Guide
How to understand virtualization
Interface types
8
155.49.3.0 / 24
155.49.4.0 / 24
155.49.5.0 / 24
155.49.6.0 / 24
155.49.7.0 / 24
Corresponding Internet route: 155.49.0.0 / 21
BLOCK #2
Allocated customer class C networks:
155.49.8.0 / 24
155.49.9.0 / 24
155.49.10.0 / 24
155.49.11.0 / 24
155.49.12.0 / 24
155.49.13.0 / 24
155.49.14.0 / 24
155.49.15.0 / 24
Corresponding Internet route: 155.49.8.0 / 21
BLOCK #3
Allocated customer class C networks:
155.49.16.0 / 24
155.49.17.0 / 24
155.49.18.0 / 24
155.49.19.0 / 24
155.49.20.0 / 24
155.49.21.0 / 24
155.49.22.0 / 24
155.49.23.0 / 24
Corresponding Internet route: 155.49.16.0 / 21
Summary
The ISP can take the traditional class B network (16 bits) it was assigned and subnet it using, in this
case, a 21-bit mask (255.255.248.0) to allocate blocks of class C networks (24 bits) to its customers
as needed, and also minimize the amount of new routes required to reach each customer's network.
McAfee Network Security Platform 8.1
IPS Administration Guide
219
8
How to understand virtualization
Interface types
Of course, the ISP could follow similar logic to further subnet one or more of these networks blocks to
accommodate even smaller customers.
Consider using one of the many subnet calculators freely available on the Internet. They often simplify
the creation of a CIDR addressing scheme, and can at least serve to check your work.
CIDR interfaces definition
The first step to using a CIDR interface is to change the interface type from Dedicated to CIDR.
The next step is to edit the interface and associate CIDR ranges with it. You'll want to define here all
the internal CIDR ranges whose traffic you anticipate traversing this interface.
The user interface expects CIDR ranges as a combination of IP network (or address) and mask length
(in bits). In Figure Adding CIDR ranges, the 192.168.0.0/24 network has already been added to the list
and the 10.0.0.0/8 network is about to be added.
Figure 8-11 Edit CIDR Interface window
The figure below shows the results of the last step:
Figure 8-12 Current CIDR range
220
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Interface types
If we look at the Devices | <Admin Domain Name> | Devices | IPS Interfaces | <Interface_Name> | Properties, the
interfaces and their corresponding policies, the CIDR interface will appear no different than the Dedicated
interface it replaced.
However, if we look back at the details of interface 3A-3B, we can confirm at a glance that it is now
associated with CIDR ranges 192.168.0.0/24 or 10.0.0.0/8:
If traffic flows through interface 3A-3B, with no source address on the 192.168.0.0/24 or 10.0.0.0/8
networks, the Default Inline policy will no longer be applied. Instead, the traffic applied will be that of
the parent (physical interface) and not the Sensor policies.
Defining CIDR sub-interfaces definition
The next step is to allocate all or part of those CIDR ranges to a sub-interface to further refine the
scanning process.
In the figure Adding a single host, we are adding a sub-interface called Unix ServersB7, assigning it
the All-Inclusive with Audit, and allocating only the IP address of the Unix server to it. (To specify a
single host, you use a 32-bit network mask):
Figure 8-13 Sub-Interface Details window
The key to successfully allocating multiple subnets from a single CIDR range is that the corresponding
sub-interfaces cannot overlap. As obvious as it might sound that you cannot allocate all or part of a
CIDR range multiple times, the flexibility of CIDR addressing can sometimes also make the
calculations confusing.
If you attempt to use a CIDR range multiple times, the user interface will return an error. Let's step
through an example to produce such an error.
At this point in the configuration process, the entire 192.168.0.0/24 CIDR range is available for
sub-interfaces, except the 192.168.0.12 IP address (our Unix server).
In the figure Adding a range, we are allocating the 192.168.0.128/25 range as well. Otherwise put, this
will allocate the IP range from 192.168.0.128 to 192.168.0.255.
McAfee Network Security Platform 8.1
IPS Administration Guide
221
8
How to understand virtualization
Interface types
If we next attempt to allocate 192.168.0.1/25, we will receive the following error:
Figure 8-14 CIDR block allocation error
The reason for the failure is that 192.168.0.0/25 allocates the IP range from 192.168.0.0 to
192.168.0.127, which includes the previously allocated IP address of the Unix server 192.168.0.12, so
this is an overlap. The error is explaining that the sub-interface was created, but no CIDR range was
actually allocated to it.
If you need a reality check while in the process of creating or editing a sub-interface, you can always
view the list of currently allocated CIDR ranges. This option is highlighted in Figure Viewing the list of
allocated CIDR blocks:
The output for the network will look as follows:
If we discard the third sub-interface (the one that returned an error) and look back at the details of
the interface, a few things have changed
Figure 8-15
Sub-interface details
The resource tree includes an icon for each new sub-interface.
Parts of the 192.168.0.0/24 CIDR range are now shown in the Details window to be associated with
the new sub-interfaces (and therefore their policies).
The details of the final configuration are as follows:
222
•
Traffic from or to IP addresses ranging from 192.168.0.128 - 192.168.0.255 will have the Default
Inline IPS policy applied to it.
•
Traffic from or to the Unix Server B7 (192.168.0.12) will have the Default Inline IPS policy applied to it.
•
Traffic from or to any other IP in the 192.168.0.0/24 CIDR range or the 10.0.0.0/8 CIDR range will
have the DMZ policy applied to it.
•
Traffic not containing any of those IP addresses will have the Default policy applied to it (the policy
assigned to the Sensor).
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
How policies are applied
We could of course create another sub-interface for all or part of the 10.0.0.0/8 CIDR range, for
example.
If we subsequently wanted to allocate yet another CIDR range to a sub-interface, we would first have
to add that range to the 1A interface.
How policies are applied
When you add a VLAN or CIDR block to a subinterface, Network Security Platform treats the
corresponding hosts as internal and builds a "protection domain" around them. All inbound traffic to
and outbound traffic from those hosts is scanned using the policy associated with the sub-interface.
Background
Each interface and subinterface has a unique ID called its "VIDS ID," and each VIDS ID is associated
with the IPS policy that you apply to the corresponding interface or subinterface. Each IPS policy in
turn, is associated with inbound and outbound rule sets, and each rule set contains a list of attack
signatures. The Sensor must therefore track the VIDS ID and direction of each flow to eventually know
which attacks (signatures, Reconnaissance, or DoS) to use when scanning it.
Similar to IPS policy, a VIDS ID is associated with the other security policies that you have applied to
the interface or subinterface.
Every time a new flow is established through a Sensor, information about the flow is added to the
Sensor's state table. The state table includes standard connection tracking information, such as source
and destination IP address/port, protocol ID, and TCP state and sequence numbers. Each state table
entry also includes the VIDS ID and direction of the flow in question.
The VIDS ID and direction are determined at the outset of the connection, for example: by the SYN
packet. The Sensor scans the entire flow using the attack signatures corresponding to the stored VIDS
ID and direction. It does notapply the inbound rule set in one direction and the outbound rule set in
the other.
The determination of VIDS ID and direction depends directly on the operational mode and interface
type in question.
Inline mode and dedicated interface
The simplest scenario is the one in which a SYN packet arrives on a port that is operating in inline
mode and configured as a dedicated interface.
As a dedicated interface, there is a single VIDS ID associated with the entire interface, so it is
straightforward to identify.
To determine direction, the Sensor considers the physical port on which the SYN packet arrives:
•
If the SYN packet arrives on the port connected to the inside network, the entire flow is considered
outbound.
•
If the SYN packet arrives on the port connected to the outside network, the entire flow is
considered inbound.
A port is defined as inside versus outside from the Configure Monitoring Port page of the Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
223
8
How to understand virtualization
How policies are applied
For example, if a client connects to a server through the 1A/1B monitoring ports, and the client's SYN
packet arrives on the outside port, all traffic in the flow is scanned using the signatures associated
with the inbound rule set and VIDS ID for the 1A/1B interface; this includes return traffic from the
server.
Sub-interfaces
If the same port on which the SYN packet arrives is instead associated with a VLAN or CIDR interface,
the Sensor applies the same logic to determine the direction of the flow, but must do additional work
to determine the VIDS ID.
If the interface type is VLAN, the Sensor compares the VLAN tag in the SYN packet against all
previously defined VLAN IDs to determine the sub-interface to which the flow belongs.
•
If the Sensor matches the VLAN in the SYN tag packet with one of its VLAN IDs, it stores the VIDS
ID of the matching sub-interface in its state table.
•
If the Sensor does not match the VLAN tag in the SYN packet with one of its VLAN IDs, it stores the
VIDS ID associated with the parent interface instead.
If the interface type is CIDR, the Sensor uses the direction of the flow to determine the sub-interface to
which the flow belongs.
•
If the flow is inbound, the Sensor compares the destination IP address of the SYN packet against
its CIDR sub-interfaces.
•
If there is a match, the Sensor stores the VIDS ID associated with the matched CIDR sub-interface.
•
Otherwise, it stores the VIDS ID associated with the parent interface.
•
If the flow is outbound, the Sensor compares the source IP address of the SYN packet against its
CIDR sub-interfaces.
•
If there is a match, the Sensor stores the VIDS ID associated with the matched CIDR sub-interface.
•
Otherwise, it stores the VIDS ID associated with the parent interface.
SPAN or tap mode
Ports in SPAN and tap mode do not provide a Sensor with the same physical means to determine
direction. In the case of SPAN mode, for example, traffic is mirrored from a switch to a single Sensor
monitoring port, so a Sensor cannot easily differentiate inbound traffic from outbound.
How the Sensor determines direction and VIDS ID in SPAN or tap mode depends on the interface type
in question.
Dedicated interface
When running a dedicated interface in SPAN or tap mode, the Sensor uses the following logic to
determine direction and VIDS ID:
224
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its destination IP address
against all known CIDR blocks.
•
If there is a match, the entire flow is considered inbound.
•
If there is not a match, the entire flow is considered outbound.
•
The Sensor stores the VIDS ID associated with the interface.
McAfee Network Security Platform 8.1
IPS Administration Guide
8
How to understand virtualization
Common use of VLAN, bridge VLAN, and CIDR interfaces
VLAN interface
When running a VLAN interface in SPAN or tap mode, the Sensor uses the following logic to determine
direction and VIDS ID:
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its VLAN interface blocks
against the destination IP address in the SYN packet.
•
If there is a match, the entire flow is considered inbound.
•
If there is not a match, the entire flow is considered outbound.
•
The Sensor compares its VLAN sub-interfaces against the VLAN tag in the SYN packet.
•
If there is a match, the Sensor stores the VIDS ID of the matched VLAN sub-interface.
•
Otherwise, the Sensor stores the VIDS ID of the parent interface.
CIDR interface
When running a CIDR interface in SPAN or tap mode, the Sensor uses the following logic to determine
direction and VIDS ID:
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its CIDR subinterfaces
against the destination IP address in the SYN packet.
•
If there is a match, the entire flow is considered inbound and the Sensor stores the VIDS ID of the
matched CIDR subinterface.
•
If there is not a match, the Sensor compares its CIDR subinterfaces against the source IP address
in the SYN packet.
•
If there is a match, the entire flow is considered outbound and the Sensor stores the VIDS ID
associated with the matched CIDR subinterface.
•
If there is not a match, the entire flow is considered inbound and the Sensor stores the VIDS ID
associated with the parent interface.
Common use of VLAN, bridge VLAN, and CIDR interfaces
There is no rule governing when to use one approach over the other. Instead, consider the most
common uses of each:
•
VLAN sub-interfaces are most common when the customer has grouped like systems by VLANs
and the Sensor resides at an aggregation point on the network. You can obviously only take
advantage of VLAN sub-interfaces when the traffic in question is trunked VLAN tagged.
•
Bridge VLAN sub-interfaces, however, have a specific use. This is applicable only for M-series
Sensors deployed in in-line mode. As the name suggests, a Bridge VLAN interface. You use this
feature to subject all inter-VLAN traffic to IPS using the minimal number of Sensors.
•
CIDR sub-interfaces have a specific use. You can create sub-interfaces and then allocate policies to
them.
McAfee Network Security Platform 8.1
IPS Administration Guide
225
8
How to understand virtualization
Interface, VLAN, and CIDR limits
Interface, VLAN, and CIDR limits
The following is a list of limits to consider when using sub-interfaces:
226
•
It is perfectly acceptable to use both VLAN and CIDR sub-interfaces on a single Sensor. As we have
seen, however, you cannot mix VLAN and CIDR sub-interfaces on a single interface.
•
Network Security Platform supports VLAN IDs 1 through 4095. Refer to McAfee Network Security
Platform Troubleshooting Guide for the maximum interface per Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
9
Troubleshooting
This section contains information that may help you solve problems you may experience with your
inline mode deployment.
Contents
Upload diagnostics trace
How to verify if traffic is flowing through the Sensor
Verification to check whether failover pair creation is successful
How to replace a Sensor
Upload diagnostics trace
The Diagnostics Trace action uploads a device diagnostics log from a Sensor or NTBA Appliance to your
Manager server. The diagnostics file includes debug, log, and other information that can be used to
determine device or NTBA Appliance malfunctions or other performance issues. Once uploaded to your
Manager, this file can be sent through email to McAfee Technical Support for analysis and
troubleshooting advice.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | Troubleshooting | Diagnostics Trace.
The <Device Name> could refer to a Sensor or an NTBA Appliance.
The Diagnostics Trace page is displayed.
Figure 9-1 Diagnostics Trace page
2
Select the Upload? checkbox if it is not already selected.
3
Click Upload.
The status appears in the Upload diagnostics Status pop-up window.
McAfee Network Security Platform 8.1
IPS Administration Guide
227
9
Troubleshooting
How to verify if traffic is flowing through the Sensor
4
Click Close Window when the message "DOWNLOAD COMPLETE" appears. The trace file is saved to
your Manager server at:
<Install Dir> \temp \tftpin \< Device Name \trace\. Once downloaded, the file also
appears in the Uploaded Diagnostics Trace Files dialog box under this action.
5
[Optional] Export a diagnostics file to a client machine by selecting the file from the Uploaded
Diagnostics Files listed and clicking Export. Save this file to your client machine. Saving the file is
particularly useful if you are logged in remotely, need to perform a diagnostics trace, and send the
file to technical support.
How to verify if traffic is flowing through the Sensor
For any inline Sensor, you can look at the statistics for each Sensor port to confirm if traffic is properly
flowing through it, by launching the Threat Analyzer.
For step-by-step procedures on verifying how to verify traffic is flowing through the Sensor, see McAfee
Network Security Platform Manager Administration Guide.
Verification to check whether failover pair creation is
successful
If you have configured a failover pair before connecting the heartbeat cables, you will notice Failover
peer status errors appearing on the System Health monitor until you connect the heartbeat cable. These
messages will not appear if the two communicate properly.
The status of the communication between the Sensors can be monitored on the Sensors | View Details
page of the Manager interface or directly from the CLI of either Sensor.
The Sensor command line interface (CLI) is a valuable tool for verifying correct configuration as well
as diagnosing possible problems.
For more information refer to McAfee Network Security Platform CLI Guide.
show
Shows all of the current configuration settings on the Sensor. You can use the show command to verify
information such as the Sensor's management port IP address, the version of software currently
running, Manager's IP address, and the gateway IP address that connect the Sensor to the Manager.
status
Shows Sensor system status, such as Operational Status, total number of alerts detected, and total
number of alerts sent to the Manager. The status command is useful for verifying that trust has been
established between the Sensor and the Manager, and for verifying the Sensor is detecting attacks and
sending alerts to the Manager.
228
•
If trust is not established, check the Sensor name and shared secret on both the Sensor and the
Manager.
•
If the Sensor is not seeing attacks for a significant period of time, check status for Sensor health
and established trust. Also, check your port configuration and cabling setup.
McAfee Network Security Platform 8.1
IPS Administration Guide
9
Troubleshooting
How to replace a Sensor
show failover-status
This command shows whether failover is enabled on the Sensor and the status of the peer Sensor. You
can run the command from either Sensor. The output includes the fields Failover Enabled (must be
YES) and Peer Status (must be UP). The former indicates whether the Sensor on which the command
is issued has been configured to be part of a Failover Pair, and the latter shows the current state of the
communication between the two Sensors.
downloadstatus
This command displays the status of various download/upload operations: signature, software image,
and DoS profile downloads (from Manager to Sensor) and DoS profile and debug trace uploads (from
Sensor to Manager).
Lists the number of times you have performed the operation, status of your previous attempt to
perform the operation (including-if the operation failed-the cause of failure), and the time the
command was executed.
How to replace a Sensor
This section describes how to replace a physical Sensor that is not functioning with a new physical
Sensor.
How to replace a failed Sensor
If a Sensor has failed and is no longer operational, you must replace it with a new Sensor.
You cannot swap out one Sensor model with another without reconfiguring the trust arrangement
between the Sensor and the Manager. If you want to, for example, replace an I-2700 Sensor with an
I-4000 Sensor, you must treat the installation and configuration as if you were installing a new Sensor.
You also cannot replace a regular Sensor with a failover-only (FO) Sensor model. These Sensors are for
use only in a failover configuration and cannot be used as a standalone Sensor.
Replace a failed Sensor with the same model Sensor
If you replace a failed Sensor with the same model Sensor (for example, replace an I-2700 with
another I-2700), you need only install the new Sensor and configure it with the same information as
the failed Sensor.
Task
1
Remove the failed Sensor. You must turn it off, unplug it from its electrical source, unplug its
cables, and remove it from its rack mounting.
2
Mount the new Sensor in the rack.
3
Follow the entire configuration process. See, Configuring the Sensor, McAfee Network Security
Platform Integration Guide. Make sure to configure the Sensor with the same name and shared key
as the failed Sensor. (You can reuse the name of the failed Sensor; however, the name must be
unique to the Sensor. The Manager will not recognize two active Sensors with the same name.)
The new Sensor does not need to have the same IP address and can reside on a different network.
(If the Sensor is on a different network from the Manager, you must set the gateway IP address,
and you may need to configure the Management port's speed and whether it is full- or half-duplex.)
See McAfee Network Security Platform CLI Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
229
9
Troubleshooting
How to replace a Sensor
4
Go to Devices | <Admin Domain Name> | Devices | <Device Name> | Maintenance | Reboot.
5
Click Reboot Now.
The Sensor restarts and is ready for operations once it comes up.
Maintenance of Sensor certificate information when replacing a
Sensor
The SSL feature is not supported on I-1200, I-1400 and the NS-series Sensors.
We recommend saving the Sensor certificate information to an external flash and then using that flash
to re-establish all Sensor certificate data if the Sensor fails and needs to be replaced. These
commands export/import the sensor certificates, which establishes trust between the Sensor and the
Manager. These certificates include the Manager public key, Sensor private key, and Sensor public key.
The compact flash should be physically secured at all times, since certificate data exported to flash is
used to validate Sensor certificate information.
Export SSL certificate data to an external flash
You can export SSL certificate data to an external flash.
Task
1
If the Sensor is up and running, type shutdown from the Sensor CLI.
2
Answer Y to the confirmation question.
3
Wait a minute, and then turn off the Sensor.
4
Insert the compact flash into the external flash receptacle on the Sensor (see the corresponding
McAfee Network Security Platform Sensor Product Guide for an illustration of the location of the
external flash port).
5
Turn on the system.
6
Log on to the Manager.
7
Once the connection and trust to the Manager is established, type
exportSensorcerts from the Sensor CLI. This exports all certificate data to the external flash.
8
Once done, repeat the shutdown procedure as described in Step 1 through Step 3.
9
Remove the external compact flash.
Never remove or insert the compact flash when the Sensor is turned on.
Import SSL certificate data from an external flash
You can import SSL certificate data from an external flash.
Task
230
1
If the Sensor is up and running, type shutdown from the Sensor CLI.
2
Answer Y to the confirmation question.
3
Wait a minute, and then turn off the Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
9
Troubleshooting
How to replace a Sensor
4
Insert the compact flash into the external flash receptacle on the Sensor (see the Sensor's McAfee
Network Security Platform Product Guide for an illustration of the location of the external flash
port).
5
Turn on the system.
6
Once the system comes up, type importsensorcerts from the Sensor CLI.
7
Once done, repeat the shutdown procedure as described in Step 1 through Step 3.
8
Remove the external compact flash.
9
Turn on the system and when it comes up it will establish trust with the Manager automatically.
Never remove or insert the compact flash when the Sensor is turned on.
Delete a Sensor from the Manager
You can delete a previously added Sensor from the Manager.
Task
1
2
Delete the Sensor from the Manager:
a
Start the Sensor software.
b
Log on to the Manager.
c
Go to Devices | <Admin Domain Name> | Global | Add or Remove Devices.
d
Select the Sensor from the Add or Remove Devices page.
e
Click Delete.
f
Confirm the deletion.
Clear the configuration information on the Sensor:
a
In the Sensor command prompt window, type deinstall.
This removes the trust relationship between the Sensor and the Manager.
b
(Optional) Type resetconfig.
This clears the configuration values on the Sensor and restarts the Sensor.
resetconfig does not clear values such as Sensor name, and Sensor IP. You must reset those
values manually.
c
Type show to view the configuration settings.
d
To exit the session, type exit.
Add a deleted Sensor back to the Manager
If you deleted a Sensor from the Manager and want to re-add it, you must reset the shared key value
on the Sensor to re-establish secure communication between the Sensor and Manager.
Task
1
Connect a terminal to the Sensor Console port. (For instructions on connecting to the Console port,
see the corresponding McAfee Network Security Platform Sensor Product Guide.)
2
At the login prompt, log on to the Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
231
9
Troubleshooting
How to replace a Sensor
3
Clear the certificates used for communication with the Sensor. At the prompt, type deinstall.
4
Type show to see the current configuration information for the Sensor.
Modify it as needed.
5
Re-enter the shared key information for the Sensor.
At the command prompt, type set sensor sharedsecretkey <WORD>.
This value is used to establish a trust relationship between the Sensor and the Manager. The secret
key value can consist of up to 25 characters of any ASCII text. The shared key value is
case-sensitive.
Example: set sensor sharedsecretkey IPSkey123.
232
6
To exit the session, type exit.
7
Re-add the Sensor to the Manager as described in Adding a Sensor to the Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
Configuring Network Security
Platform for intrusion prevention
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
IPS policies
IPS Policy user interfaces
Working with IPS policies
Device Profiling and Alert Relevance
Advanced Malware Policies
Advanced botnet detection
Denial-of-Service attacks
Inspection of SSL traffic
How McAfee identifies applications?
Working with Reconnaissance policies
Firewall policies
Quality of Service policies
How to create exceptions for an applied IPS policy
Protecting web applications servers and inspecting HTTP traffic
Quarantining hosts
Quarantining virtual machines using third-party applications
Inspection of special traffic types
Advanced Traffic Inspection
Layer 7 data collection
Exporting Layer 7 data to NTBA appliances
IP Reputation
Using a Sensor to capture data packets
IP spoofing detection
Enable layer 2 settings
Configure IP Settings
Configure TCP Settings
Configuring non-standard ports
Network forensics
McAfee Network Security Platform 8.1
IPS Administration Guide
233
Configuring Network Security Platform for intrusion prevention
234
McAfee Network Security Platform 8.1
IPS Administration Guide
10
IPS policies
In Network Security Platform, all the major features, including IPS, are policy based. For example, for
IDS/IPS, you use IPS policies and recon policies. Similarly, for the Firewall feature, you use the
Firewall policies. This chapter introduces the security policies in Network Security Platform and
provides the conceptual details for IPS policies. Other security policies such as the Firewall policies and
Advanced Malware policies are discussed in their respective sections.
Contents
Network Security Platform policies
How policies are applied
Components of an IPS policy
Classification of attack definitions
Severity level calculation of attacks
Pre-configured rule sets and policies
Configuration of policies
How to block attacks
How to respond to detected attacks
Network Security Platform policies
Generally, a security policy in Network Security Platform is a set of rules defining the activity you want
the Sensors to detect and how you want to respond if that activity is detected. The activity that a rule
is to detect need not be a malicious one always. For example, you can define a Firewall rule to always
allow all types of traffic from your CEO's laptop. 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 following are the type of security policies in Network Security Platform:
•
IPS policies
•
Firewall policies
•
Reconnaissance policies
•
QoS policies
•
Advanced Malware policies
•
Connection Limiting policies
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. Except for some policies, McAfee Network Security Platform enables rule-based
policies for your network resources, right down to individual sub-flows of network traffic. For certain
policy types, several pre-configured policies are supplied for immediate application.
Imagine a network that has Windows and Linux hosts interspersed across it. The best approach for
IPS here is to apply a policy that includes attacks for both Windows and Linux on all ports through
which their traffic flows. 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
McAfee Network Security Platform 8.1
IPS Administration Guide
235
10
IPS policies
How policies are applied
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.
How policies are applied
When you add a VLAN or CIDR block to a subinterface, Network Security Platform treats the
corresponding hosts as internal and builds a "protection domain" around them. All inbound traffic to
and outbound traffic from those hosts is scanned using the policy associated with the sub-interface.
Background
Each interface and subinterface has a unique ID called its "VIDS ID," and each VIDS ID is associated
with the IPS policy that you apply to the corresponding interface or subinterface. Each IPS policy in
turn, is associated with inbound and outbound rule sets, and each rule set contains a list of attack
signatures. The Sensor must therefore track the VIDS ID and direction of each flow to eventually know
which attacks (signatures, Reconnaissance, or DoS) to use when scanning it.
Similar to IPS policy, a VIDS ID is associated with the other security policies that you have applied to
the interface or subinterface.
Every time a new flow is established through a Sensor, information about the flow is added to the
Sensor's state table. The state table includes standard connection tracking information, such as source
and destination IP address/port, protocol ID, and TCP state and sequence numbers. Each state table
entry also includes the VIDS ID and direction of the flow in question.
The VIDS ID and direction are determined at the outset of the connection, for example: by the SYN
packet. The Sensor scans the entire flow using the attack signatures corresponding to the stored VIDS
ID and direction. It does notapply the inbound rule set in one direction and the outbound rule set in
the other.
The determination of VIDS ID and direction depends directly on the operational mode and interface
type in question.
Inline mode and dedicated interface
The simplest scenario is the one in which a SYN packet arrives on a port that is operating in inline
mode and configured as a dedicated interface.
As a dedicated interface, there is a single VIDS ID associated with the entire interface, so it is
straightforward to identify.
To determine direction, the Sensor considers the physical port on which the SYN packet arrives:
•
If the SYN packet arrives on the port connected to the inside network, the entire flow is considered
outbound.
•
If the SYN packet arrives on the port connected to the outside network, the entire flow is
considered inbound.
A port is defined as inside versus outside from the Configure Monitoring Port page of the Manager.
For example, if a client connects to a server through the 1A/1B monitoring ports, and the client's SYN
packet arrives on the outside port, all traffic in the flow is scanned using the signatures associated
with the inbound rule set and VIDS ID for the 1A/1B interface; this includes return traffic from the
server.
236
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
How policies are applied
10
Sub-interfaces
If the same port on which the SYN packet arrives is instead associated with a VLAN or CIDR interface,
the Sensor applies the same logic to determine the direction of the flow, but must do additional work
to determine the VIDS ID.
If the interface type is VLAN, the Sensor compares the VLAN tag in the SYN packet against all
previously defined VLAN IDs to determine the sub-interface to which the flow belongs.
•
If the Sensor matches the VLAN in the SYN tag packet with one of its VLAN IDs, it stores the VIDS
ID of the matching sub-interface in its state table.
•
If the Sensor does not match the VLAN tag in the SYN packet with one of its VLAN IDs, it stores the
VIDS ID associated with the parent interface instead.
If the interface type is CIDR, the Sensor uses the direction of the flow to determine the sub-interface to
which the flow belongs.
•
If the flow is inbound, the Sensor compares the destination IP address of the SYN packet against
its CIDR sub-interfaces.
•
If there is a match, the Sensor stores the VIDS ID associated with the matched CIDR sub-interface.
•
Otherwise, it stores the VIDS ID associated with the parent interface.
•
If the flow is outbound, the Sensor compares the source IP address of the SYN packet against its
CIDR sub-interfaces.
•
If there is a match, the Sensor stores the VIDS ID associated with the matched CIDR sub-interface.
•
Otherwise, it stores the VIDS ID associated with the parent interface.
SPAN or tap mode
Ports in SPAN and tap mode do not provide a Sensor with the same physical means to determine
direction. In the case of SPAN mode, for example, traffic is mirrored from a switch to a single Sensor
monitoring port, so a Sensor cannot easily differentiate inbound traffic from outbound.
How the Sensor determines direction and VIDS ID in SPAN or tap mode depends on the interface type
in question.
Dedicated interface
When running a dedicated interface in SPAN or tap mode, the Sensor uses the following logic to
determine direction and VIDS ID:
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its destination IP address
against all known CIDR blocks.
•
If there is a match, the entire flow is considered inbound.
•
If there is not a match, the entire flow is considered outbound.
•
The Sensor stores the VIDS ID associated with the interface.
VLAN interface
When running a VLAN interface in SPAN or tap mode, the Sensor uses the following logic to determine
direction and VIDS ID:
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its VLAN interface blocks
against the destination IP address in the SYN packet.
•
If there is a match, the entire flow is considered inbound.
McAfee Network Security Platform 8.1
IPS Administration Guide
237
10
IPS policies
Components of an IPS policy
•
If there is not a match, the entire flow is considered outbound.
•
The Sensor compares its VLAN sub-interfaces against the VLAN tag in the SYN packet.
•
If there is a match, the Sensor stores the VIDS ID of the matched VLAN sub-interface.
•
Otherwise, the Sensor stores the VIDS ID of the parent interface.
CIDR interface
When running a CIDR interface in SPAN or tap mode, the Sensor uses the following logic to determine
direction and VIDS ID:
•
When a SYN packet arrives on a SPAN or tap port, the Sensor compares its CIDR subinterfaces
against the destination IP address in the SYN packet.
•
If there is a match, the entire flow is considered inbound and the Sensor stores the VIDS ID of the
matched CIDR subinterface.
•
If there is not a match, the Sensor compares its CIDR subinterfaces against the source IP address
in the SYN packet.
•
If there is a match, the entire flow is considered outbound and the Sensor stores the VIDS ID
associated with the matched CIDR subinterface.
•
If there is not a match, the entire flow is considered inbound and the Sensor stores the VIDS ID
associated with the parent interface.
Components of an IPS policy
An IPS policy is one of the many types of security policies used in Network Security Platform. A Sensor
uses the assigned IPS policy to determine if the detected traffic is free of attacks according to that
policy. An IPS policy is for detecting exploit attacks, policy violations, and DoS attacks. Also, the IPS
policy determines how a Sensor responds when it detects traffic that violates an IPS policy.
The main components of an IPS policy are the Rule Sets and the Attack definitions. An IPS policy is
essentially a set of attack definitions for various protocols (HTTP, UDP), operating systems (Windows,
NT, Solaris), and other types of information transmitted across your network. In addition to other
anomalies in the detected traffic, the Sensor also checks if that traffic matches with what is defined in
an attack. If a match is found, that means the corresponding attack was attempted.
In an IPS policy, a Rule Set for inbound and a Rule Set for outbound is specified. It can be the same
Rule Set for both inbound and outbound or different ones. The Rule Sets specified in the IPS policy
determine the attack definitions to be included in the IPS policy.
There are quite a few predefined IPS policies provided for you to deploy Network Security Platform
out-of-the box. You can use them or create your own.
To create and use IPS policies, familiarize yourself with the terminologies discussed here.
Rule Set— The best practice is to create multiple, specific IPS policies that focus on the specific needs
of unique zones in your network, rather than a one-size-fits-all policy for the entire network.
Therefore, the attack definitions are internally classified based on:
238
•
Whether they are exploits, malwares, policy violation, and so on
•
The relevant protocols, such as FTP, HTTP, RADIUS, and so on
•
The relevant operating systems
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Classification of attack definitions
•
The applications such as Skype and Google Search that attacks are relevant for
•
The chances of attacks being false-positives
10
In a Rule Set, you can specify the categories of attacks that must be included and the categories that
must be excluded. Then when you specify this Rule Set in the IPS Policy, the Manager processes the
Signature Set and identifies the attack definitions according to what you specified in the Rule Set. Only
these attack definitions are included in the IPS policy.
In the Manager, there are several provided rule sets which match the preconfigured policies. You can
view, clone (copy), and customize these rule sets for your own use.
Rules— You specify the categories of attacks to be included and the ones to be excluded in a Rule
Set. To do so, you define Rules in a Rule Set. 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 encompasses a
broad range of well-known attacks for detection. An exclude rule removes elements from the include
rule to focus the policy's rule set. By broadening (includes) and narrowing (excludes) the rules, you
can enable detection for the attacks that affect the intended environment.
If you have an exclude rule, an include rule added afterward might negate the exclusion For example,
if you specify an exclude rule for the DNS protocol, then later include multiple protocols including DNS,
the exclusion rule is negated.
Signature Set— This is the complete set of attack definitions developed and provided by McAfee
Labs. The Signature Set enables Network Security Platform to properly detect and protect against
malicious activity. The Manager and the Sensors must be frequently updated with the latest signatures
and software patches made available to you via the Update Server.
Attack definitions and signatures— Note that as you interact with Network Security Platform
policies, you encounter the term attack, not signature. Network Security Platform defines an attack as
being comprised of one or more signatures, thresholds, anomaly profiles, or correlation rules, where
each method is used to detect an attempt to exploit a particular vulnerability in a system. These
signatures and checks might contain 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.
Custom Attacks— There could be unique security requirements that would not be possible to be
covered in the McAfee-supplied signature set. For such cases, you have the option of developing your
own attack definitions. Such user-defined attacks are referred to as custom attack definitions or
custom attacks. The Manager factors in the Custom Attacks as well when it calculates the attack
definitions to be included according to a Rule Set. Custom Attacks are exclusively covered in the
McAfee Network Security Platform Custom Attack Definitions Guide.
Classification of attack definitions
As mentioned earlier, the attack definitions are classified based on multiple factors. This classification
is to enable you to include only the relevant attacks in your IPS policies. Factors such as protocols,
operating systems, and applications are straight-forward. Factors that require some explanation are
discussed in the following sections.
Attack categories
When a system vulnerability has been discovered, an attacker can threaten the system with an attack
that affects the system. The attack categories, also known as attack type, detail the general types of
attacks that can be performed to a system.
McAfee Network Security Platform 8.1
IPS Administration Guide
239
10
IPS policies
Classification of attack definitions
Attack category
Description
Exploit
This category covers most attack activities that actively seek to compromise
systems, gain unauthorized access to system or services, or tamper normal
system operations by exploiting known or potential system vulnerabilities.
Malware
Malware is the short form for malicious software. It can be defined as a piece of
harmful software code created and spread with a malicious intent. Examples
are virus programs, Trojan horses, computer worms, spyware, and botnets.
In general, the objective of the attacks in this category is to steal system or
user confidential information and send it back to the server controlled by the
attacker. Targeted information includes things such as the user name, host
name, user passwords, and license keys. Some other common characteristics
of the attacks in this category include spamming, launching DoS attacks,
downloading additional malicious code, and downloading updates to the
malicious code.
Policy violation
An attacker performed an action that goes against the organizational or system
policy, possibly by attempting to gain access they are not authorized to have.
This includes all activities for which the underlying traffic content might 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.
Reconnaissance
This type of activities is for intelligence gathering to prepare for further
attacks; for example, a port scan or probe conducted to enumerate or identify
services and possible vulnerabilities.
DoS and DDoS
A denial of service (DoS) or distributed denial of service (DDoS) attack was
performed, possibly harming the ability of the network or system to respond or
continue providing services.
Multi Sensor
correlation
Manager correlates the attack detection information from multiple intrusion
detection systems (Sensors) to identify different phrases of the attack
behaviors.
Protocol discovery
Sensor determines protocol anomaly on well-known ports such as P2P software
running on a well-known port.
Multi method
correlation
Multiple detection methods are used to correlate the attacking traffic to identify
different phrases of the attack behaviors. Examples of such correlation are
attack signature, Network Security Platform shellcode detection, and statistical
correlation.
Flow correlation
Sensor correlates the bi-directional traffic of each session to increase the
accuracy of the attack detection as well as impact of the attack.
Application anomaly This type of attack is caused when a large number of bytes comes from an
HTTP browser than that are actually going onto it. An example of such an
attack is Buffer Overflow.
Attack subcategories
Attack subcategories are the specific, inherent system flaws that can be exploited by attackers familiar
with a vulnerability. A known vulnerability poses a threat to the system; the attacking party exploits
this threat with an attack that is designed to affect some part of the vulnerable system. The following
table captures some of the Attack subcategories.
240
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Classification of attack definitions
10
Category
Description
Audit
Any networking event deemed to be of interest to the security analyst. Examples
include invocation of particular applications or use of particular commands in
certain applications.
Back Door
Depending on the confidence level of the triggers, this can either be some
attempts at contacting a backdoor process or the occurrence of actual backdoor
two-way conversation. If the latter has occurred, it means that a backdoor
process exists in your network, the backdoor user is in your network, or both are
inside your network, depending on the locations of the communication endpoints.
Brute Force
Brute force attacks are used by programs, such as password crackers, to try many
different passwords to guess the proper one.
Buffer Overflow
This kind of alerts indicates attempts at exploiting 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.
Command Shell
Traffic activities indicating interactive shells under Unix or Windows operating
systems, and so forth.
Covert Channel
Any communication activities that are deemed unintended by the communication
channel being monitored.
DDoS Agent
Activity
Known DDoS attack tools use various patterns of communication among 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.
DoS
Well-crafted packets, for example with invalid/inconsistent TCP/UDP/IP header
values, aiming at crashing the target TCP/IP stack or causing high resource
consumption.
Evasion Attempt
This kind of alert indicates a sequence of packets or bytes in the traffic signifying
a specific attempt at evading an IDS. 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.
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 operating system or host type.
Host Sweep
Well-defined sequence of packets sweeping through a range of destination IP
addresses, typically aiming at identifying live hosts.
Non-standard
Port
Any traffic activities suggesting that a standard protocol running over
non-standard ports according to specifications.
Over Threshold
Any of the well-defined traffic thresholds has been crossed. Examples include
ICMP packet rate, IP fragment rate, and so forth.
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.
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 permission 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,
for example unusual flag settings.
Protocol Violation Unusual application protocol behaviors, including invalid field values or invalid
command sequences, and so forth.
McAfee Network Security Platform 8.1
IPS Administration Guide
241
10
IPS policies
Classification of attack definitions
Category
Description
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.
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 permission elevation once
remote access is obtained.
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.
Sensitive Content Any content keyword matches that are deemed to indicate transmission of
sensitive information, for example document with "Company Confidential"
marking.
242
Shellcode
Execution
This kind of alert indicates the most severe form of buffer overflow attacks, that
is, 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, modifies the target's configuration or behavior for malicious purposes.
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.
Unassigned
This category is for attacks that fall outside the scope of the known subcategories
in the Network Security Platform 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.
Virus
Any network event or payload specifically related to a virus. A malicious virus can
inflict many different types of damage to its target, ranging from stealing or
destroying information to installing backdoor processes. However, a virus relies on
other carriers, for example, email, to propagate through the network.
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, and so on; this will
cause a DoS effect on other legitimate traffic.
Worm
Any network event or payload specifically related to worm activities. A malicious
worm can inflict many different types of damages to its target, ranging from
stealing or destroying information to installing backdoor processes. The worm
differs from a virus in that it can propagate itself through the network.
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, for example breach of
access control by adding an illegal user account records.
Arbitrary
Command
execution
An attacker can execute system commands and scripts, like getting a directory
listing on a system, thus stealing and destroying data. The attacker who is able to
access a user's system can exploit the vulnerability and install malicious software
and use the system to launch attacks on other systems.
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Classification of attack definitions
10
Category
Description
Code execution
A vulnerability which can be exploited by malicious people to compromise a user's
system. An attacker can execute malicious programs or code on a user's system.
Successful exploitation allows execution of arbitrary code and possibly takes
complete control of the affected system. Attacker can run code with elevated
permissions.
If a user is logged on with administrative user rights, an attacker who successfully
exploited this vulnerability could take complete control of an affected system. An
attacker could then install programs; view, change, or delete data; or create new
accounts with full user rights. Users whose accounts are configured to have fewer
user rights on the system could be less affected than users who operate with
administrative user rights.
Bot
Refers to a group of computers running or executing a program that allows an
attacker to control the system remotely and make users execute commands like
DOS. These commands are taken place in the IRC channel.
A 'bot' is a type of malware which allows an attacker to gain complete control over
the affected computer. Computers that are infected with a 'bot' are generally
referred to as 'zombies'. Attackers are able to access lists of 'zombie' PC's and
activate them to help execute DoS (denial-of-service) attacks against Web sites,
host phishing attack Websites or send out thousands of spam email messages.
A bot worm is a self-replicating malware program that resides in current memory
(RAM), turns infected computers into zombies (or bots) and transmits itself to
other computers. A bot worm may be created with the ultimate intention of
creating a botnet that functions as a vehicle for the spread of viruses, Trojans and
spam.
Service-sweep
An alert indicates that a client scans for services on your network or sub network
thus leading to increased bandwidth corruption and increase in network traffic. It
is usually generated by a P2P client. A Service Sweep is an attempt to determine
if a service is running on a range of machines. The hacker will pick one port
(usually 25-SMTP, 80-HTTP, or 139-NetBIOS SSN) and a range of IP addresses.
A Ping Sweep is an attempt to see which machines in a network are on and
responding.
The easiest way to detect these in a trace is to look for ARP packets. So, create a
filter looking for ARP requests.
Phishing
An email-fraud method in which the perpetrators send out legitimate looking
email in attempt to gather personal and financial information from recipients.
Typically, the messages appear to come from well-known and trustworthy
websites. Websites that are frequently spoofed by phishers include oBey, MSG,
Yahoo, etc.
"Phishing" is a form of Internet fraud that aims to steal valuable information such
as credit cards, social security numbers, user IDs, and passwords. A fake website
is created that is similar to that of a legitimate organization, typically a financial
institution such as a bank or insurance company. An email is sent requesting that
the recipient access the fake website (which is usually a replica of a trusted site)
and enter their personal details, including security access codes.
PUP
A PUP (potentially unwanted program) is a program that may be unwanted,
despite the possibility that users consented to download it. PUBs include spyware,
adhere, and dialers, and are often downloaded in conjunction with a program that
the user wants. McAfee differentiates PUBs from other types of malware, such as
viruses, Trojans, and worms, which can be safely assumed to be unwanted by the
user.
McAfee Network Security Platform 8.1
IPS Administration Guide
243
10
IPS policies
Classification of attack definitions
Protection categories
In Network Security Platform, attacks are traditionally classified based on their type. For example, an
attack can be an exploit attack, reconnaissance attack, DoS attack, or a policy violation. These
categories are referred to as attack categories. Attacks are also classified based on the intent of the
attack and the intended target. For example, an attack targeting vulnerabilities in client operating
systems is classified under Client Protection/Operating System. These are referred to as protection
categories.
There are two levels in protection categories. The first-level classification is at a broader level and can
indicate whether an attack is a malware or whether it is targeted at clients or servers. Each of these
categories has subcategories that can indicate the specifics of an attack. See the examples shown in
the following diagram.
Figure 10-1
Examples of protection categories and protection subcategories
For McAfee-defined attacks, McAfee® Labs classifies the attacks into one or more protection categories.
In case of McAfee custom attacks, you can specify a relevant protection category for each attack
definition.
Protection categories help you to relate attacks better. For example, an attack classified as an exploit
that targets client operating systems is more informative than just being classified as an exploit
attack. You can also view the attack definitions related to a specific category in a policy. For example,
you can check what are the attack definitions you have in your policy to protect your DNS servers.
Thus, you can map attack definitions to the network resources you want to protect.
In the Threat Analyzer, the protection category feature facilitates analysis that is more granular. For,
example you can analyze whether it is the clients or servers that are being attacked. Similarly, you
can generate reports based on protection categories.
244
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Severity level calculation of attacks
10
Notes:
•
Currently you can only filter based on protection categories when you view exploit attack
definitions. This display filter is only available in the IPS Policies page and not in the Default IPS Attack
Settings page (formerly Global Attack Response Editor or GARE).
•
In the Recon Policy Editor, you cannot filter attack definitions based on protection categories. However,
in the Threat Analyzer, protection category detail is displayed for recon attacks as well.
•
In the Custom Attack Editor, when you create an exploit or recon McAfee custom attack, you can
specify the protection category. This is not relevant for Snort Custom Attacks.
Protection category details in the Threat Analyzer and reports
In the Threat Analyzer, the protection category is displayed for each alert, if available. The number of
protection categories, to which the corresponding attack belongs, is displayed. For example, if the
displayed number is 2, it means the attack belongs to two protection categories. To view the names of
these categories, move the mouse over the number. You can group the alerts by protection categories.
Select Protection Categories from the Group By drop-down. For information regarding the Threat Analyzer,
see McAfee Network Security Platform Manager Administration Guide.
When you create a Next Generation User Defined report based on Alert Data, you can include
protection category as one of the columns in the report. You can also use it as a Data Filter for the
report. For information on Next Generation User Defined Reports, see McAfee Network Security
Platform Manager Administration Guide.
Severity level calculation of attacks
Network Security Platform assigns a default severity (high, medium, or low) to every attack in its
attack database. Severity is based on the immediate effect, or impact, on the target system.
Severity numbering scheme
Network Security Platform uses a numeric mapping scheme to indicate Informational, Low, Medium,
and High severity for a more intuitive display. The numbering scheme is as follows:
INFORMATIONAL
LOW
MEDIUM
HIGH
0
1-3
4-6
7-9
The guidelines in assigning severity levels are very similar to those used in many open security
forums. You can customize these severity levels to meet the needs of your system based on the worth
of your protected assets—an attack whose severity might be considered Low to one company might be
High to another.
Attack categories and severity range
Network Security Platform categorizes attacks into four groups: Reconnaissance, Exploits, Volume
DoS, and Policy Violation. The following table illustrates how severity levels are assigned for attacks in
different categories.
Category
Threat type
Range used in Network Security Platform
Reconnaissance
Host sweep
4-4
Port scan
4-4
Brute force
4-6
McAfee Network Security Platform 8.1
IPS Administration Guide
245
10
IPS policies
Pre-configured rule sets and policies
Category
Exploits
Volume DoS
Policy Violation
Threat type
Range used in Network Security Platform
Service sweep
6-6
OS Fingerprinting
6-6
Protocol Violation
3-5
Buffer Overflow
7-9
Shellcode Execution
7-9
Remote Access
5-9
Privileged Access
8-9
Probe
2-2
DoS
3-5
Evasion Attempt
7-7
Arbitrary Command Execution
8-8
Code/Script Execution
7-7
Bot
7-9
Trojan
3-9
DDoS Agent Activity
7-9
Backdoor
7-9
Worm
6-9
Virus
3-5
Read Exposure
3-5
Write Exposure
5-7
Statistical Deviation
7-7
Over Threshold
6-6
Audit
0-0
Restricted Access
4-5
Restricted Application
4-5
Unauthorized IP
5-5
Sensitive Content
5-7
Covert Channel
5-5
Command Shell
4-4
Non-standard Port
4-4
Phishing
1-5
Potentially Unwanted Program
1-3
Pre-configured rule sets and policies
McAfee provides many pre-configured rule sets and policies for immediate application in a number of
different network areas. Each pre-configured policy is matched with an identically named rule set
designed to address the common attacks targeting specific network environments. To provide the
246
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Pre-configured rule sets and policies
10
most efficient attack detection options, these policies take into account distinct factors such as
protocols (HTTP, SMTP, DNS), applications (email, FTP, web), and operating systems (Windows,
Solaris, Linux).
You cannot edit or delete pre-configured policies or rule sets. However, you may clone a pre-configured
rule set or policy, then rename and customize it.
Preconfigured policies
McAfee supplies a set of preconfigured policies for immediate application in a number of different
network environments. These policies are available in the IPS Policy Editor, which is located under the
Policy page of the Manager.
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 inline mode). As you tune your IPS, you will modify these policies
to best suit your particular environment.
Each preconfigured 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 following are pre-formatted policies and their descriptions.
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 4 (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.
McAfee Network Security Platform 8.1
IPS Administration Guide
247
10
IPS policies
Pre-configured rule sets and policies
Policy
Designed to Protect Against
Internal Segment
All attacks except for Exploits using RIP and routing protocol attacks.
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 Server
All attacks where the impacted OS includes Windows, Linux, or Solaris.
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 Network Security Platform 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 All-Inclusive without Audit, 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. Alternatively,
you can use Firewall Access Rules to exempt this traffic from IPS.
For example, in the following figure, an I-2700 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.
248
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Pre-configured rule sets and policies
10
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 Network Security Platform. 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 10-2 Deploy security policies
Preconfigured Rule Sets
McAfee supplies a set of preconfigured Rule Sets that correspond to the preconfigured IPS Policies as
well. You can use these Rule Sets to create specific IPS policies according to your requirements. That
is, you can clone these Rule Sets and modify them to create custom IPS Policies. These pre-defined
Rule Sets are available in the Rule Sets page, which you can access from the Policy page.
Rule Sets
Designed to Protect Against:
Default IDS
All attacks.
Default Inline IPS
All attacks and McAfee-recommended blocking of selected attacks
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.
Web Server
All Reconnaissance and DoS attacks, generic backdoors, and Exploits using
DNS, HTTP, and FTP protocols.
McAfee Network Security Platform 8.1
IPS Administration Guide
249
10
IPS policies
Configuration of policies
Rule Sets
Designed to Protect Against:
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 Server
All attacks where the impacted OS includes Windows, Linux, or Solaris.
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 Network Security Platform 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.
Configuration of policies
Your policy determines what traffic analysis your Sensor will perform. Network Security Platform
provides a number of policy templates to get you started toward your ultimate goal: prevent attacks
from damaging your network, and limit the alerts displayed in the Threat Analyzer to those which are
valid and useful for your analysis.
There are two stages to this process: initial policy configuration and policy tuning. Policy tuning is
renowned to be a tedious task. However, because networks and attacks constantly evolve, the policy
tuning process is never truly complete. Instead, you might equate it to a disk defragmentation; the
more often you do it, the less time each check takes. The ultimate goal of policy tuning is to eliminate
false positives and noise and avoid overwhelming quantities of legitimate, but anticipated alerts.
Tune your policies
This center point of this section is the IPS policy, but conceptually it is relevant to some of the other
security policies of Network Security Platform as well.
250
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Configuration of policies
10
The pre-defined IPS policies are provided as a generic starting point; you will want to customize one of
these policies for your needs. So the first step in tuning is to clone the most appropriate policy for
your network and your goals, and then customize it. (You can also edit the policy directly.) Some
things to remember when tuning your policies:
•
We ask that you set your expectations appropriately regarding the elimination of false positives and
noise. A proper Network Security Platform implementation includes multiple tuning phases. False
positives and excess noise are routine for the first 3 to 4 weeks. Once properly tuned, however,
they can be reduced to a rare occurrence.
•
When initially deployed, Network Security Platform frequently exposes unexpected conditions in the
existing network and application configuration. What may at first seem like a false positive might
actually be the manifestation of a misconfigured router or Web application, for example.
•
Before you begin, be aware of the network topology and the hosts in your network, so you can
enable the policy to detect the correct set of attacks for your environment.
•
Take steps to reduce false positives and noise from the start. If you allow a large number of "noisy"
alerts to continue to sound on a very busy network, parsing and pruning the database can quickly
become cumbersome tasks. It is preferable to all parties involved to put energy into preventing
false positives than into working around them. One method may be is to disable all alerts that are
obviously not applicable to the hosts you will protect. For example, if you use only Apache Web
servers, you may want to disable IIS-related attacks.
Attack Defaults
Attack Defaults are essentially a 'shortcut' to customizing a particular attack's response across all
policies containing that attack. Responses configured at the Attack Defaults 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 Attack Defaults, 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 Attack Defaults editor, Attack Defaults displays the default attack
values specified by the signature set. Attack Defaults thus "inherits" the response actions from the
signature set. Customizing these values in the Attack Defaults 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 Attack Default.
Attack Defaults values are then available for customization at the Rule set level. For example, at the
Rule set level, you inherit all the customization from the Attack Defaults level, but can set a response
action of "blocking" for certain attacks. Now the attack can have the Attack Defaults customization
plus the Rule set customization.
Finally, you have the Policy level. All the customization made at the Rule set level or at the Attack
Defaults level are inherited at the Policy level.
McAfee Network Security Platform 8.1
IPS Administration Guide
251
10
IPS policies
Configuration of policies
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 10-3 Rule set
The IPS Policy Editor now displays labels showing at what level an attack was customized:
D – Default Network Security Platform-supplied
D – Default IPS Attack Settings
R – Rule Set Editor (only blocking action)
P – IPS 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 (RFSB) 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 DEfault IPS Attack Settings level for FTP: Attack Example, configure packet logging and
email notification.
2
At the Rule Set level, enable blocking for RFSB 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.
Default IPS Attack Settings customization can be imported/exported using the Policy Import/Export
feature.
252
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
Configuration of policies
10
False positives and noise
The mere mention of false positives always causes concern in the mind of any security analyst.
However, false positives may mean quite differently things to different people. To better manage the
security risks using any IDS/IPS devices, it's very important to understand the exact meanings of
different types of alerts so that appropriate response can be applied.
With Network Security Platform, there are three types of alerts that are often taken as "false
positives":
•
Incorrectly identified events
•
Correctly identified events subject to interpretation by usage policy
•
Correctly identified events uninteresting to the user.
Incorrect identification
These alerts typically result from overly aggressive signature design, special characteristics of the user
environment, or system bugs. For example, typical users will never use nested file folders with a path
more than 256 characters long; however, a particular user may push the Windows' free-style naming
to the extreme and create files with path names more than 1024 characters. Issues in this category
are rare. They can be fixed by signature modifications or software bug fixes.
Correct identification — significance subject to usage policy
Events of this type include those alerting on activities associated with instant messaging (IM), internet
relay chat (IRC), and peer-to-peer programs (P2P). Some security policies forbid such traffic on their
network; for example, within a corporate common operation environment (COE); others may allow
them to various degrees. Universities, for example, typically have a totally open policy for running
these applications. Network Security Platform provides two means by which to tune out such events if
your policies deem these events uninteresting. First, you can define a customized policy in which these
events are disabled. In doing so, the Sensor will not even look for these events in the traffic stream to
which the policy is applied. If these events are of interest for most of the hosts except a few, creating
exception objects to suppress alerts for the few hosts is an alternative approach.
Correct identification — significance subject to user sensitivity (also known
as noise)
There is another type of event that you may not be interested in, due to the perceived severity of the
event. For example, Network Security Platform will detect a UDP-based host sweep when a given host
sends UDP packets to a certain number of distinct destinations within a given time interval. Although
you can tune this detection by configuring the threshold and the interval according to their sensitivity,
it's still possible that some or all of the host IPs being scanned are actually not live. Some users will
consider these alerts as noise, others will take notice because it indicates possible reconnaissance
activity. Another example of noise would be if someone attempted an IIS-based attack against your
Apache Web server. This is a hostile act, but it will not actually harm anything except wasting some
network bandwidth. Again, a would-be attacker learns something he can use against your network:
the fact that the attack failed can help him zero in on the type of Web server you use. Users can also
better manage this type of events through policy customization or installing exception objects.
The noise-to-incorrect-identification ratio can be fairly high, particularly in the following conditions:
•
The configured policy includes many Informational alerts, or scan alerts which are based on request
activities (such as the All Inclusive policy)
•
Deployment links where there much hostile traffic, such as in front of a firewall
•
Overly coarse traffic VIDS definition that contains disparate applications. For example, a highly
aggregated link in dedicated interface mode
McAfee Network Security Platform 8.1
IPS Administration Guide
253
10
IPS policies
How to block attacks
Users can effectively manage the noise level by defining appropriate VIDS and customize the policy
accordingly. For dealing with exceptional hosts, such as a dedicated pentest machine, exception
objects can also be used.
How to block attacks
The ability to drop and deny traffic is available only with a Sensor running in inline mode. The most
efficient way to block exploits is to customize one or more of the pre-defined IPS policies to
pro-actively drop malicious traffic. One of the pre-configured policies includes this functionality by
default. The Default Inline IPS policy is automatically applied to Sensor interfaces when the Sensor is first
added to the Manager. This policy contains a number of attacks that Network Security Platform has
categorized as "recommended for smart blocking" (RFSB), and which are pre-configured with the drop
attack packets response.
With other provided policies, the default Sensor response is to send alerts and log packets.
The first step towards prevention is typically to block attacks that have not caused false positives,
have a high severity level, and have a low benign trigger probability. When you know which attacks
you want to block, you can configure your policy to perform the drop attack packets response for
those attacks.
Methods for blocking attacks
The Network Security Platform IPS offers a variety of ways to block malicious traffic. These options
include the following:
•
Block exploit traffic (based on IPS policy configuration)
•
Block DoS traffic (behavior-based detection)
•
Block malware download (based on Malware policies)
•
Block using Firewall policies (based on ACLs in the Firewall policies)
•
Use Network Security Platform's traffic normalization feature—block based on configured TCP flow
violation (out-of-order packets, deny…)
•
Block IP-spoofed packets (configured)
Exception Objects can be configured to override the blocking criteria—to permit particular source
IPs, for example.
The Malware, Firewall, and DoS are detailed in their respective chapters of this Guide.
How to block exploit traffic
Exploit refers to attacks that are discovered through a set of parameters, or rules, that are matched
against data within a packet. Signatures, specific strings used to match data in offending packets, are
the key method in discovering an exploit. An attack can have multiple signatures; thus, enabling more
than one chance at attack detection.
Using the Policy Editor, you can enable the blocking option for the required attacks.
254
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
How to block attacks
10
How blocking works for exploit traffic
•
The Sensor applies the configured inbound or outbound policy depending on the traffic direction,
which is determined via the Sensor cabling and port configuration.
•
The Sensor analyzes the traffic and, based on the policy, determines whether the traffic is "good"
(does not match an attack configured in the policy) or "bad" (matches an attack configured in the
policy). If the traffic is bad, the Sensor then applies the configured "drop packets" action. When
Network Security Platform identifies a malicious flow, it blocks only the flow; not all the traffic from
the source IP address (Sensor behavior is unlike that of a firewall).
•
For UDP and ICMP traffic, only the attack packet is blocked. With TCP traffic, the entire attack flow
is blocked; we recommend that you also configure a TCP Reset action in the policy to reset the
flow.
When inline, the TCP resets always go out the inline ports. Response ports are used when the device
is configured for tap or span mode.
Verification of dropped exploit attacks using Threat Analyzer
The Alert Result Status graph within the Threat Analyzer's Consolidated View displays the results of
detected attacks as determined by target response (that is, Successful, Failed) or Network Security
Platform action (that is, Blocked). "Blocked" specifically refers to the attacks that have been dropped
due to policy response settings. Within a Threat Analyzer query, you can see the number of attacks
that have been blocked during the query's time period.
•
The result status "blocked" will increment for each blocked attack.
•
If you drill down by "Status" in a particular alert, the result status will show as "Blocked."
Use of traffic normalization
Traffic normalization—available when the system is operating in inline mode—removes any traffic
protocol ambiguities, protecting the end systems by cleaning up potentially harmful traffic in real time.
Traffic normalization consists of two Sensor techniques: cleaning up malformed packets, and dropping
illegal packets—for example, packets where the IP header is smaller than 20 bytes, IP fragments
smaller than 64KB, and so on. Traffic normalization also thwarts any attempts to evade the system
while boosting attack detection accuracy. This feature, also known as protocol scrubbing or packet
scrubbing allows Network Security Platform systems to prevent hackers from fingerprinting a host
system. Often attackers send abnormal traffic in the hope that the end system responds in a way that
allows the attacker to determine what environments and technologies are deployed at a particular site.
This makes it easier to launch subsequent attacks against known vulnerabilities in host network
hardware or software resources.
Specifically, when enabled, normalization does the following:
•
When the TCP Timestamp option is not negotiated in the SYN/SYN_ACK packet for a connection,
but appears in any of the packets for the rest of the connection, the TCP Timestamp is removed
from the headers of these packets.
•
The MSS option is permitted only in the SYN/SYN_ACK packets for a TCP connection. If any other
packets in the flow contain the MSS option, the Sensor removes it.
In both cases, Network Security Platform performs an incremental checksum of the TCP header and
regenerates the CRC integrity check value.
Packet scrubbing must be manually enabled. In the System page select the Domain, click Devices and then
select the Sensor. Then go to Policy | Advanced | TCP Settings and enable Normalization On/Off Option); dropping
of illegal packets is a default Sensor behavior.
McAfee Network Security Platform 8.1
IPS Administration Guide
255
10
IPS policies
How to block attacks
How to block based on configured TCP/IP settings
Sensors have the intelligence to keep a number of TCP/IP connection parameters, as well as complete
state information. The Devices | <Domain name> | Devices | <Device Name> | Policy | Advanced | TCP Settings and
Devices | <Domain name> | Devices | <Device Name> | Policy | Advanced | IP Settings action enables you to
configure 16 TCP/IP parameters, such as the number of supported UDP flows, the TCB inactivity timer
length, and accepting old data or new data for TCP or IP overlaps. All of the TCP/IP Settings
parameters relate to the handling of monitored transmissions while in inline mode. You can use these
settings to deny or drop certain traffic.
Two of the more notable parameters are as follows:
•
Cold Start Drop Action — When starting a Sensor for the first time, you can decide to allow (forward) or
drop all packets that do not have a flow control block recognized by the Sensor. You have the
choice to Forward Flows or Drop Flows.
•
TCP Flow Violation — How to handle a packet received for a connection that doesn't exist, such as an
ACK packet when no SYN for a connection has been received. Choices are:
•
Permit — Reassembles out-of-order packets and processes them. It forwards traffic if strict TCP
protocol violations and if State Not Established on Sensor fails.
•
Permit out-of-order — Allows out of order packets to continue to transmit without processing.
Select Permit out-of-order selected if your Sensor is deployed in an asymmetrical environment to
avoid session dropping.
•
Deny — Checks the flow for strict TCP protocol violations; if it discovers violations, it drops the
packet and reassembles out-of-order packets.
•
Deny no TCB — (Deny if state is not established) drops the session only if the state has not been
established. It forwards traffic only if strict TCP protocol violations fails.
•
Stateless Inspection — Does not consider the flow for inspection.
How to block IP-spoofed packets
When enabled, the anti-spoofing option drops packets containing invalid source IP addresses. Network
Security Platform determines the validity of a source IP address by comparing it against a configured
list of internal networks. Thus, as a pre-requisite, you must define CIDR blocks for every internal
network that will send traffic through the Sensor interface in question. Without a comprehensive set of
CIDR blocks defined, especially if outbound anti-spoofing is enabled, Network Security Platform may
block valid packets.
Anti-spoofing is available only for Sensors in inline mode.
How Network Security Platform determines the validity of a packet depends directly on the direction of
that packet, as follows:
256
•
Inbound — When a packet arrives on the outside interface, its source IP address is compared to the
CIDR blocks associated with the interface. If the source IP address of the inbound packet matches
one of the CIDR blocks, the packet is considered spoofed and dropped.
•
Outbound — When a packet arrives on the inside interface, its source IP address is compared to the
CIDR blocks associated with the interface. If the source IP address of the outbound packet does not
match one of the CIDR blocks, the packet is considered spoofed and dropped.
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
How to respond to detected attacks
10
How to respond to detected attacks
When a McAfee® Network Security 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 denial of service (DoS) 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 impact severity is recommended for effective network
security.
Since the Sensors can be installed anywhere in a network, knowing what area a Sensor protects is
important for determining the response type. If installed outside of the firewall, alerting with response
is best used for DoS and other attacks against the firewall. Most other suspicious traffic types that are
not recognized by known signatures intended for the internal network, including scans and CGI data,
are best logged without response, then analyzed as the impact is not immediate and a better
understanding of the potential attack purpose can be determined.
Setting a response type during policy configuration is critical for an effective intrusion management
system.
Response management
When a 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 Network Security Platform can be customized to protect any zone in a network,
knowing what needs to be protected can help to determine the response type. If 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.
McAfee Network Security Platform 8.1
IPS Administration Guide
257
10
IPS policies
How to respond to detected attacks
Response types
The response types offered by Sensors and Manager are as follows:
Sensor response actions
Sensor actions are responses your Sensor enacts or sends through the network to prevent or deter
further attacks.
•
Drop further packets (Inline mode only) — Dropping the specific attack packets is a key advantage of
inline mode. When detecting inline (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 Threat Analyzer. Alerts can be examined for content and sorted by
key fields such as severity level, source and destination IP addresses, and so forth. For more
information on the Threat Analyzer, see the McAfee Network Security Platform Manager
Administration Guide.
•
Quarantine— Sensor performs the quarantine of infected host, by isolating the host for a specified
period.
•
Packet log — Sends a log, or copy, of the packet information to the Manager 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 Threat Analyzer, 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. In the IPS Policy Editor/ Default IPS Attack Settings,
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. For more information, see
Viewing a packet log, McAfee Network Security Platform Manager Administration Guide.
•
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.
•
Exception Objects — Creating exception object 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 Exception Object Editor provides a convenient interface for creating exception objects.
•
ICMP host unreachable — ICMP Host Unreachable packets can be sent in response to the source of UDP
or ICMP attacks.
Recommended for Smart Blocking (RFSB)
Network Security Platform 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 RFSB 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.
258
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS policies
How to respond to detected attacks
10
Simulated Blocking
Simulated Blocking enables you to put the Sensor in a non-blocking mode whereby exploit attacks are
not blocked even if the applied IPS policy is configured to do so. Alerts are still raised based on the
configured policy. When Simulated Blocking is enabled, response actions that affect the flow of traffic
— blocking, sending a TCP reset, and sending an ICMP host unreachable message are not applied. This
feature does not affect the Quarantine actions.
This feature allows an IPS sanity check where you get to know the specific attacks that would have hit
a blocking rule, that is, which attacks would be blocked during normal operation without actually
blocking them (the alerts explicitly mention that blocking has been simulated). You can use this
feature to also temporarily disable blocking for troubleshooting.
Simulated blocking applies to signature-based attack definitions only. Denial-of-Service and
reconnaissance attacks will continue to activate response actions if configured to do so.
Simulated Blocking does not change the behavior certain features of the Sensor. Further, these
features will need to be disabled individually if required. The following list includes all such features:
•
DoS blocking
•
Host quarantine
•
Artemis blocking
•
IP sanity errors checks
•
ACL drop action
You may choose to enable Simulated Blocking and configure the response action in your policy as a
TCP Reset or ICMP Unreachable. In such instances, the Sensor does not carry out a designated
response action; the Result column in the Threat Analyzer displays one of the standard attack results,
such as Attack Failed, Attack Successful, Attack Blocked, Inconclusive, or n/a. These attack result statuses are
identical to those that are displayed when Simulated Blocking is disabled.
Disable Simulated Blocking before performing an upgrade using the CLI. This allows data in the
Manager to synchronize with the Sensor immediately after the upgrade. If not disabled, the first sigfile
push will disable this option (by default it is disabled at device level). For more information, see McAfee
Network Security Platform CLI Guide.
Configure Simulated Blocking at the interface level
You can configure Simulated Blocking at the interface level.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
McAfee Network Security Platform 8.1
IPS Administration Guide
259
10
IPS policies
How to respond to detected attacks
5
Select IPS Interfaces | <Interface-x Name> | Protection Profile.
By default, Simulated Blocking is disabled for the entire device.
Figure 10-4 Simulated Blocking dialog
6
Select Simulated Blocking for inbound/outbound traffic.
Simulated Blocking is not supported separately for the traffic directions. If one is configured
(enabled/disabled), the other is also configured similarly.
7
8
From the Simulated Blocking drop-down list, make a selecton.
•
To enable Simulated Blocking device wide, select Simulation enabled for the entire device.
•
To disable Simulated Blocking device wide, select Simulation disabled for the entire device.
•
To control Simulated Blocking per VIDS, select Enable simulation per interface.
Click Save.
•
The device level settings override the interface level settings, that is, you cannot configure
Simulated Blocking at the interface level if it is configured at the device level.
•
The set ipssimulation disable and show ipssimulation status commands are used to
manage Simulated Blocking. For more information, see McAfee Network Security Platform CLI
Guide.
Packet logging
Logging attack packets for analysis is an effective means of preparing for future attacks. A packet log
is created by a Sensor capturing the network traffic around an offending transmission. An expert in
protocol analysis can use the log information to determine what caused the alert and what can be
done to prevent future alerts of the same nature. Packet logs are retrieved from the database via the
Threat Analyzer and can be opened and examined using a program called Ethereal. By default, UDP
and TCP protocol attacks generate a packet log for the attack plus the previous 128 bytes in the flow.
You can configure to enable previous 256 bytes logging using the Sensor CLI. For more information,
see the McAfee Network Security Platform CLI Guide.
McAfee recommends using Wireshark (formerly known as Ethereal) for packet log viewing. Ethereal is a
network protocol analyzer for Unix and Windows servers that enables you to examine the data captured
by your Sensor. For information on downloading and use of Ethereal, go to www.wireshark.com.
260
McAfee Network Security Platform 8.1
IPS Administration Guide
11
IPS Policy user interfaces
To be able to work with IPS Policies of Network Security Platform, you must be familiar with the
concepts related to IPS Policies as well with the Manager user interfaces related to IPS Policies. The
preceding chapters dealt with the concepts in detail. This chapter begins with the description of user
interfaces related to Rule Sets and then proceeds to IPS Policy. Review this chapter to familiarize
yourself with these user interfaces and to know how to use the options available in them.
Contents
Rule Sets page
IPS Policies Page
Rule Sets page
Recall that Network Security Platform provides a long list of pre-defined rule sets. The Rules Sets page
displays the pre-defined rule sets and the user-defined rule sets available for the selected admin
domain.
Task
1
In the Manager, click Policy and select the required Domain.
2
Select Intrusion Prevention | Advanced | Rule Sets.
The Rule Sets page is displayed.
The options in this page are as follows:
•
Rule Set Name — The name assigned to the Rule Set.
•
Owner — The domain to which the rule set belongs. All pre-defined Rule Sets belong to the root
admin domain (My Company).
McAfee Network Security Platform 8.1
IPS Administration Guide
261
11
IPS Policy user interfaces
Rule Sets page
3
•
Editable — Indicates whether you can edit or delete a Rule Set from the current admin domain.
You cannot edit or delete the pre-defined Rule Sets. You can edit or delete a user-defined Rule
Set only from the admin domain from which it was created.
•
You can sort the list of Rule Sets in the ascending or descending order. Click one of the column
headings. This might enable you to locate Rule Sets.
•
Click New to create a rule set. The Definition and Rules tabs are explained in the sections that
follow.
•
Select a Rule Set and click Clone to clone it. This is helpful especially if you want to use a
non-editable Rule Set with slight changes.
•
Select on any of the listed rule sets and click View/Edit to view it. Select an editable rule set and
click View/Edit to edit it.
•
Select an editable Rule Set and click Delete to delete.
To view the constituent attack definitions of a Rule Set, select it and click View Attacks Selected.
The attack definitions categorized based on protocols are listed with the number of attacks and
number of enabled attacks per protocol.
You can double-click a row to view the attack definitions.
You can further double-click an attack to view the attack details. However, all these pages are only
for viewing.
262
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS Policy user interfaces
Rule Sets page
11
Definitions tab
The Add a Rule Set page has two tabs. The first one is the Definitions tab where you provide the name and
description for the Rule Set. You can also specify if you want to enable SmartBlocking. This option is
discussed subsequently along with the steps to create a Rule Set.
Rules tab
The Rules tab is where you can manage the Rules in a Rule Set. Recall that Rules can be of two types include or exclude. The Rules tab displays the rules of a rule set. To create a rule, click Insert.
Double-click a row to see the details of the rule.
McAfee Network Security Platform 8.1
IPS Administration Guide
263
11
IPS Policy user interfaces
IPS Policies Page
IPS Policies Page
Recall that Network Security Platform provides some pre-defined IPS Policies. The IPS Policies page
displays the pre-defined IPS Policies and the user-defined IPS Policies available for the selected admin
domain.
Task
1
In the Manager, click Policy and then select the required Domain.
2
Go to Intrusion Prevention | IPS Policies.
The IPS Policies page is displayed.
The options in this page are as follows:
264
•
Policy Name — The name assigned to the IPS Policy.
•
Owner — The domain to which the IPS Policy belongs. All pre-defined IPS Policies belong to the
root admin domain (My Company).
•
You can sort the list of IPS Policies in the ascending or descending alphabetical order. Click one
of the column headings. This might enable you to locate an IPS Policy.
•
Inbound Rule Set — Indicates the Rule Set applied for the inbound traffic.
•
Outbound Rule Set — Indicates the Rule Set applied for the outbound traffic.
•
Last Modified — The time stamp of when a policy was last modified.
•
Last Modified By — The logon name of the user who last modified it.
•
Assignments — The number of interfaces and subinterfaces to which a policy is assigned. This
information is according to the current information in the Manager database. Click the link in the
Assignments column to assign the corresponding policy to the required interfaces and
subinterfaces.
•
Editable — Indicates whether you can edit or delete an IPS Policy from the current admin domain.
You can edit but not delete the pre-defined IPS Policies. You can edit or delete a user-defined
IPS Policy only from the admin domain from which it was created.
•
Click New to create an IPS Policy. The Properties and Attack Definitions tabs are explained in the
sections that follow.
•
Select an IPS Policy and click Clone to clone it. This is helpful especially if you want to use a
non-editable policy with slight changes.
•
Select on any of the listed policies and click View/Edit to view it. Select an editable policy and click
View/Edit to edit it.
•
Select more than one IPS Policy and click Bulk Edit to effect the same changes in all the selected
policies.
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS Policy user interfaces
IPS Policies Page
11
•
Select an eligible policy and click Delete to delete. Make sure this policy is not assigned to any
Sensor resources.
•
When you modify an IPS Policy, a new version is created that has the changes. Click Version
Control for options.
Properties tab
The Properties tab is to manage the basic properties such as name, description, the rule set for inbound
and outbound, and DoS response.
Attack Definitions tab
As the name suggests, the Attack Definitions tab lists the inbound and outbound attack definitions
included in the IPS Policy. An IPS Policy typically contains thousands of attack definitions. So, the Attack
Definitions tab has some useful filtering options to locate attack definitions.
McAfee Network Security Platform 8.1
IPS Administration Guide
265
11
IPS Policy user interfaces
IPS Policies Page
There are two options to filter the displayed attack definitions: Quick Filter and Advanced Display Filtering.
The Attack Definitions page has two main sections. The top section contains the Quick Filter section and the
option to specify an Advanced Display Filter. The bottom section lists the attacks that match the filter
criteria that you specify.
The options in the bottom section where the attacks are listed are as follows:
•
Click a column header to sort based on ascending or descending order. The primary column based
on which the list is sorted is indicated by the number 1.
•
To sort based on multiple columns, hold the Ctrl key and click the required column headings.
Click All (clear drilldown) to reset the sorting.
266
•
Right-click the header row to show, hide, align, and rename columns.
•
Right-click an attack definition to enable/disable it or to edit it with respect to the current IPS
Policy.
•
Select multiple attack definitions and right-click to bulk edit or enable/disable in bulk with respect
to the current IPS Policy.
•
Double-click an attack to edit it with respect to the current IPS Policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS Policy user interfaces
IPS Policies Page
11
•
Mouse-over any graphical icons to view the details.
•
For a consolidated view of the attack definitions, select Group by and then select the criteria based
on which you want to consolidate the attack definitions.
Apply a Quick Filter
The Quick Filter option enables you to instantly filter the attack definitions spontaneously.
Task
1
2
In the Attack Definitions tab, click
to display the Quick Filter section.
If you want to specify based on Attack Name, enter full or part of the attack name.
Wild cards are not supported. The Manager looks for attack names that contain the string that you
entered.
3
If required specify the options for Direction, Severity, RFSB, and Industry Attack ID.
In Industry Attack ID, you can enter the full or part of the ID. NSP stands for Network Security
Platform, that is McAfee-specified ID for the attack.
4
For Protection Categories, expand the required category and select the categories.
You cannot select a Protection Category name but only the options listed under a category. To select
options belonging to multiple Protection Categories, press the Ctrl key and select. Use of the Shift key
is also supported.
McAfee Network Security Platform 8.1
IPS Administration Guide
267
11
IPS Policy user interfaces
IPS Policies Page
5
Select the required Protocols and Responses and click Apply.
The Manager applies this filter on the currently listed Attack Definitions in the bottom section of the
Attack Definitions page. That is, if the bottom section is displaying a filtered list of attack definitions,
this new filter is applied on those and not on the entire list of attack definitions.
The Quick Filter link next to All (clear drilldown) corresponds to the filtered attack definitions. If you click
All (clear drilldown), the filter is removed and all the attack definitions are listed. This action also resets
the filter criteria that you specified.
6
To save the Quick Filter criteria, click Save Filter and convert it into an Advanced Display Filter.
This enables you to reuse the filter when required.
Create and apply an advanced display filter
You can save the frequently used filter criteria as an Advanced Display Filter and use it when required.
Task
1
In the Attack Definitions tab, click Advanced Display Filtering and click New Filter.
2
Enter a name for the Advanced Display Filter.
3
Click the right-arrow for the required criteria and specify the values for them.
The selected criteria move over to the right-hand pane.
268
McAfee Network Security Platform 8.1
IPS Administration Guide
IPS Policy user interfaces
IPS Policies Page
4
11
Click Save and Apply when finished.
The filtered attack definitions are listed.
If you click All (clear drilldown), the filter is removed and you must reapply the filter. It is possible to
apply a filter over an already filtered list. You can also apply a Quick Filter on top of an Advanced
Display Filter or the reverse.
McAfee Network Security Platform 8.1
IPS Administration Guide
269
11
IPS Policy user interfaces
IPS Policies Page
5
270
Click Advanced Display Filtering for options to apply, edit, and delete a saved Advanced Display Filter.
McAfee Network Security Platform 8.1
IPS Administration Guide
12
Working with IPS policies
Using the Manager you can create, edit, clone, delete rule sets and IPS policies. You can modify the
various specifications in an attack description according to your requirement. Before you proceed to
work with rule sets and IPS policies, make sure you possess the conceptual information regarding IPS
policies as well as familiarity with the IPS policy user interfaces.
Contents
How to manage rule sets?
How to manage IPS policies
Attack descriptions
How to export and import policies
Assign IPS and reconnaissance policies at the admin-domain level
Assign policies for a Sensor
Assign IPS policies to interfaces and subinterfaces
Protection profile management at the interface level
The IPS Sensor interface node
Deploy pending changes to a device
Import a Sensor configuration file
Export the Sensor configuration
Alert notification options
How to manage rule sets?
Rule sets enable the use of a powerful tool for defining the exact environment resources you want to
protect. To recap, a rule set consists of select attacks specific to a network environment, such as the
operating systems you employ, the installed applications (email, chat), and the transport and
application protocols (HTTP, FTP) used for data delivery. The protocol field includes all of the attacks
detected by Network Security Platform for specific selection by attack name, severity, and the chance
a signature may trigger a false positive. Each rule you configure narrows the detection focus of your
Sensor interfaces (where policy is applied) to provide the highest degree of detection accuracy and
performance.
The Rule Sets page provides the following functions:
•
Viewing a rule set.
•
Adding a rule set.
McAfee Network Security Platform 8.1
IPS Administration Guide
271
12
Working with IPS policies
How to manage rule sets?
•
Cloning a rule set. Cloning duplicates an existing rule set, and is similar to a "save as" function. You
can clone any rule set to further refine the parameters for the characteristics of a new
environment. You can clone a provided rule set, save it under a new name, and customize it to
meet the needs of your unique environment.
Cloning a provided rule set specifically enables you to add/subtract from the default settings of a
rule set. For example, you may not want to see alerts for Low severity attacks, thus you would
clone and customize a rule set to reflect a minimum severity of 4 (Medium) for all attacks.
•
Editing a rule set. Editing a rule set allows you to make the changes necessary to better define the
environment you will be monitoring. You can edit only the rule sets you have created; the
preconfigured policies cannot be edited. Editing a user-created rule set permanently changes that
rule set.
•
Deleting a rule set. You cannot delete currently applied rule sets and non-editable rule sets.
Create a rule set
Sensors support both normal blocking and SmartBlocking. SmartBlocking is the blocking of attacks
based on Benign Trigger Probability (BTP) value of the attack signatures which trigger the attack.
McAfee recommends certain attacks for SmartBlocking, and these are referred to as Recommended for
SmartBlocking (RFSB) attacks. While creating a Rule Set, you can enable SmartBlocking for those
exploit, recon, or policy violation attacks for which McAfee has recommended SmartBlocking.
When working within the Rule Sets, the task of creating or modifying settings opens up to four separate
Java windows. Each window has an OK and Cancel button. Clicking OK saves the information and closes
the window. Clicking Cancel ends any operation and closes the window. If you want to continue creating
or modifying a policy, do not click OK until you have completed every tab, step, or action available.
Task
1
In the Manager, click Policy and select the required Domain.
2
Select Intrusion Prevention | Advanced | Rule Sets.
The Rule Sets page is displayed.
3
Click New.
The Add a Rule Set window displays.
4
In the Definition tab, type a name and, if required, a description for your rule set.
The domain displayed below the Description corresponds to the currently selected domain. The
Rule Set that you are creating belongs to this domain.
272
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage rule sets?
5
12
To enable SmartBlocking, select Enable SmartBlocking for McAfee Recommended for SmartBlocking (RFSB) attacks in
this Rule Set.
Four blocked categories are displayed — Exploit, Malware, Reconnaissance, and Policy Violation. Select at
least one of the above categories; else an error message pops-up asking you to select at least one
category.
6
Click Save to save the changes made in the Definition tab of the rule set.
7
Select the Rules tab.
8
Click Insert.
The Insert a Rule at current position window displays.
9
Select the rule to be either an Include or Exclude rule. Include rules identify the attacks that match
the selected parameters and add them to the Rule Set. Exclude rules remove the corresponding
attacks from the list of included attacks.
Your first rule in a rule set must be an Include rule. If you list an Exclude rule first, a later include
rule may negate the exclusion.
For example, if you view the Default rule set, the rule set includes all DoS and Reconnaissance
attacks, includes all Exploit attacks above a level 2 (low) severity and below a level 4 (medium)
Benign Trigger Probability, thus excluding a specific list of attacks that contain signatures that have
a high chance of triggering a false positive alert.
McAfee Network Security Platform 8.1
IPS Administration Guide
273
12
Working with IPS policies
How to manage rule sets?
10 Do one of the following:
a
To include only specific attacks to your rule set, select the Select Specific Attacks Only checkbox and
click Configure.
The Configure the Rule by Specific Attacks window enables you to select specific attacks rather than
narrowing by environment parameters. To custom select attacks, deselect the Select All Attacks
checkbox. Use
and
to toggle attacks between Selected Attacks and Available Attacks lists.
Figure 12-1 Configure The Rule By Specific Attacks window
Click OK when done with the Configure the Rule by Specific Attacks window to return to the Insert a Rule at
current position window. Your selected attacks appear in the Rule Content table. Click OK to return to
the Add a Rule Set window. You can add more include and exclude rules to your rule set or
continue on with policy configuration.
a
274
Click Configure, without selecting the Select Specific Attacks Only checkbox. A new pop-up opens titled
Configure the Rule. Continue to Step 11.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage rule sets?
12
11 View the Category tab. By default, all four categories are selected. Categories are classifications for
all attacks.
(Optional) To custom select categories, deselect the Select All Categories checkbox. All categories are
moved to the Available Categories field. Select the category you want to add from Available Categories,
then click
then click
. To remove a selected category, select a category from the Selected Categories field,
.
Figure 12-2 Configure The Rule window — Category tab
12 Click the Protocol tab. By default, all protocols are selected. The Protocol tab lists the application
protocols supported by Network Security Platform.
(Optional) To custom select protocols, deselect the Select All Protocols checkbox (box should then be
empty). All protocols are moved to the Available Protocols field. Select the protocols you want to add
from Available Protocols, then click
. To remove an added protocol, select a protocol from the
Selected Protocols field, then click
.
13 Click the OS tab. By default, all operating systems are selected.
(Optional) To custom select an operating system, deselect the Select All OS checkbox. All operating
systems are moved to the Available OS field. Select the operating system you want to add from the
Available OS field, then click
filed, then click
. To remove an added operating system, select it from the Selected OS
.
McAfee Network Security Platform 8.1
IPS Administration Guide
275
12
Working with IPS policies
How to manage rule sets?
14 Click the Application tab. By default, all applications are selected.
(Optional) To custom select applications, deselect the Select All Applications checkbox (box should then
be empty). All applications are moved to the Available Applications field. Select the applications you
want to add from the Available Applications field, then click
. To remove an added application,
select an application from the Selected Applications field, then click
.
15 Click the Severity tab. By default, all severities are selected. The Severity parameter relates to the
well-known attacks enforced by your rule set. Severity describes the system impact an attack can
have.
(Optional) To custom select a minimum attack severity for a rule, deselect the Select All Attack Severities
checkbox (box should then be empty). From the Minimum Attack Severity drop-down list, select the
lowest possible severity of attacks you want to include in/exclude from your rule.
16 Click the Benign Trigger Probability tab. By default, all probabilities are selected. The Benign Trigger
Probability parameter relates to the well-known attacks enforced by your rule set, specifically
regarding the chance a signature in an attack may raise a false alarm.
(Optional) To custom select a minimum attack severity for a rule, deselect the Select All Benign Trigger
Probabilities checkbox (box should then be empty). From the Maximum Benign Trigger Probability drop-down
list, select the highest probability of attacks you want to include in/exclude from your rule.
17 Click the SmartBlocking tab.
Check the option, Only include McAfee Recommended for Smart Blocking (RFSB) attacks in this Rule. When you
select this option, only RFSB attacks are included in this rule.
18 Click OK when done with the configuration of this single rule. (You have made changes within the
Configure the Rule tabs.)
19 Go to the Insert a Rule at current position window to view a summary of the parameters you have set
for the rule.
20 Click OK when you are done configuring rules.
21 Go to the Add a Rule Set window.
Your new rule appears in the table as the first entry.
22 Repeat the relevant steps to add more rules to this rule set.
23 Return to the Add a Rule Set window.
When you are done adding rules to your rule set, you can perform one of the following actions:
•
Insert— Create a rule for the rule set.
•
Clone— Clone an existing rule in the rule set.
•
View/Edit— Open an existing rule to view the parameters and make changes.
•
Delete— Remove a rule.
•
Move Up— Move a rule up in the list so it is checked earlier.
•
Move Down— Move a rule down in the list so it is checked later.
24 Click Save to save your rule set.
The Add a Rule Set window closes. Your new rule set is listed at the bottom of the Rule Set List table.
276
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
12
How to manage IPS policies
The Manager provides an ultimate refining tool for IPS policy management, by bringing together
exception objects and rule sets for final customization before deployment. Using IPS policies, you can
select the exact Exploit and Denial of Service (DoS) attacks you want to protect against, the types of
automatic responses you need to block current or further impacts, and the methods of notification that
will help your team respond to malicious use of your network in the most expeditious time.
The IPS Policies page provides the following actions:
•
Adding an IPS policy.
•
Cloning an IPS policy. Cloning duplicates an existing policy, and is similar to a "save as" function.
You can edit a Network Security Platform-provided policy. However, if you want to edit a copy of a
policy, you can clone any existing policy to further refine the policy for application in a new
environment. You can clone a pre-defined policy, save it under a new name, and customize it for
your unique environment.
Cloning a provided policy specifically enables you to add/subtract from the default settings of a
policy. For example, you may find a signature is generating false positives, thus you may want to
disable the alerting of the signature's attack. Also, you may receive attacks uncommon to a
network environment that are affecting your system and you want to add specific attacks to a
policy for added security.
•
Use the link in the Assigned Resources column to assign the corresponding policy to the required
interfaces and subinterfaces.
•
Viewing/editing an IPS policy. Editing an IPS policy allows you to make the changes necessary to
match the policy with the traffic you are monitoring. Editing a policy permanently changes that
policy. However, every time you edit a policy, a new version is created. This enables you to revert
the changes by going back to an older version. To make modifications or updates to a policy, try
the following:
•
If you intend to make slight changes to a policy but want to save it under a different name, try
cloning an IPS policy.
•
If you edit a pre-defined policy and later want to recreate that policy as it was when provided by
McAfee, simply revert to the earlier version of the policy. If you had deleted the earlier versions,
add a policy and apply the inbound and outbound rule set that matches the original policy you
want to recreate.
•
If setting the same responses for several attacks serves your policy customization (for example,
enabling the Drop Packets response for all high severity attacks once you have enabled inline
mode), try the Bulk Edit option.
The IPS Policies page, the Last Modified column displays the time stamp of when a policy was last
modified. The Last Modified By column displays the logon name of the user who modified it. For policies
defined in the Central Manager, the Last Modified By column shows NSCM Defined Policy as the value.
•
Using Bulk Edit for IPS policies.
•
Deleting an IPS policy.
Add an IPS policy
Before you begin
You select the rule sets for inbound and outbound when you create an IPS Policy. These
rule sets determine the attack definitions that are included in the policy. Thus, this action of
selecting the rule sets defines the very purpose of the IPS policy. Make sure the rule sets
that you intend to use in the IPS Policy are available.
McAfee Network Security Platform 8.1
IPS Administration Guide
277
12
Working with IPS policies
How to manage IPS policies
Adding a policy in IPS policy takes you through the process of refining the parameters for securing
your network. The following procedure explains the essential elements of a complete policy
configuration.
Inbound and outbound refer to the direction that traffic is flowing with regard to the network. Inbound
refers to traffic destined for the internal network, and outbound refers to traffic destined for the
external network. McAfee recommends applying different rule sets for inbound and outbound traffic for
the following reason: traffic coming into a network area, such as the DMZ, may only require the DMZ
rule set, while traffic leaving the DMZ may be headed for external networks, thus a more generic rule
set such as the Default rule set better protects the outbound traffic.
Separate rule sets for inbound and outbound can be applied to Sensors in SPAN or tap mode. If the
Sensor is unable to determine the direction of the traffic, it enforces the inbound rule sets.
While working within IPS policies, the task of creating or modifying settings opens up to four separate
Java windows. Each window has either a Save or OK button as well as a Cancel button. Clicking Save saves
the information to the database and closes all policy configuration actions. Clicking OK closes the
subwindow that has been opened from within policy configuration, saving any changes made in that
subwindow. Clicking Cancel ends any operation and closes the window. If you want to continue creating
or modifying a policy, do not click either Save or OK until you have completed every tab, step, or action
available in a window.
Task
1
In the Manager, click Policy and select the required Domain.
2
Select Intrusion Prevention | IPS Policies.
The IPS Policies page is displayed.
3
Click New.
The New Policy window opens with the Properties tab selected.
4
Update the following fields:
Field name
Description
Name
Name of the policy
Description
Description of the policy
Make this policy visible to Specifies whether the policy is applicable to all child admin domains.
child Admin Domains?
Granularity
The extent to which the attack definitions are to be set. The available
options are:
• Maintain distinct sets of attack definitions for each direction (more flexible)
Use this option if you want to manage inbound and outbound attacks
separately.
• Use a single set of attack definitions for the entire policy (simpler)
278
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
Field name
Description
Rule Set
Rule set for inbound and outbound traffic.
Sensitivity
Defines the level of sensitivity to potential Denial-of-Service attacks. The
sensitivity levels are:
12
• Low
• Medium
• High
5
Click Calculate Attack Definitions.
The Attack Definitions tab opens.
Figure 12-3 Attack Definitions tab
New IPS attack definitions are also added for high risk hosts. This allows you to block/quarantine a
host outright if it is a high risk.
McAfee Network Security Platform 8.1
IPS Administration Guide
279
12
Working with IPS policies
How to manage IPS policies
6
Click Save.
The Summary window is displayed with the details of the Policy Attributes.
Figure 12-4 Summary window
You can type any comments in the Optional Comment text field. Refer to the subsequent sections for
more information regarding comments.
7
Click Finish.
How to add Audit Log comments
You can add comments on the IPS policy that you create.
The Summary window is displayed after you click Save when you create an IPS Policy. This window allows
you to enter a comment after you have made changes to the existing action. The comments can be
viewed by clicking the description hyperlink in the Audit Log table.
The Summary window pops up only if the EMS property "iv.ui.commit.comment.isEnforced" is set to TRUE
(default). Disabling this property causes the dialog not to pop-up.
Users can turn off the option by setting the value to FALSE in file "config\ems.properties". In this case,
users will not be prompted with a dialog that displays attribute changes and commit comment text
entry when committing changes.
If the "iv.ui.commit.comment.isEnforced.isCommentMandatory" property (Default FALSE) is set to
TRUE, then the user is forced to enter a comment in the Commit Comment field. This property can only
be used if "iv.ui.commit.comment.isEnforced" is set to enabled.
View the user activity log
You can view the comments on IPS policies that are created.
Task
280
1
In the Manager, click Manage and select the required Domain.
2
Select Troubleshooting | User Activity Log.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
3
12
Click View Messages.
View the messages in the user activity log table.
Figure 12-5 User Activity Log table
4
Click the link to view the page.
The Audit Data Details page is displayed.
5
Click Back to return to User Activity Audit log page.
Assign an IPS policy from the IPS Policies page
Before you begin
Make sure the IPS policies that you want to assign to Sensor resources are available.
In McAfee® Network Security Platform, IPS policies are enforced at the interfaces and subinterface, not
at the Sensor level. Since the Sensors are multi-port and thus multi-interface and multi-subinterface,
this allows multiple policies to be enforced within a single Sensor rather than a single catch-all policy.
Compared to some other IPS products, this is like having several Sensors in one box.
When you create an admin domain, you can select the default IPS and reconnaissance policies for that
admin domain. When you add a Sensor to that domain or allocate interfaces and subinterfaces, these
policies are applied to those Sensor resources by default. You can assign different policies to those
Sensor interfaces and subinterfaces through the corresponding Protection Profile page. An alternative
method is to assign an IPS policy from the IPS Policies page itself. This is especially useful when you
want to define an IPS policy and also quickly assign it to Sensor interfaces and subinterfaces.
Task
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | IPS Policies
McAfee Network Security Platform 8.1
IPS Administration Guide
281
12
Working with IPS policies
How to manage IPS policies
4
Click the Assigned Resources value of the policy that you want to assign.
The Assignments window displays.
5
Assign the IPS policy to the required interfaces and subinterfaces.
Figure 12-6 Assignments window
Table 12-1 Option definitions
Option
Definition
Search Resources
To filter the list of available resources, enter a string that is part of the Available
Resources.
Available Resources Lists the interfaces and subinterfaces of the Sensors in the admin domain. The
Sensor resources to which you have already assigned this IPS policy are
displayed under Selected Resources.
In case of Sensors in failover, the ports used for interconnection of the Sensors
are not displayed. If you assign an IPS policy to an interconnect port, the
assignment is automatically removed when you create the failover pair.
Select a resource and click
Current Policy
to move it to Selected Resource.
The IPS policy that is currently assigned to a resource. To replace that policy
with the policy that you are currently assigning, move the resource to Selected
Resource.
Selected Resources Lists the Sensor resources to which you have assigned the selected IPS policy.
282
Reset
Reverts to last saved configuration.
Save
Saves the changes to the Manager database.
Cancel
Closes the Assignments window without saving the changes.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
6
12
If you move a Sensor resource from Selected Resources to Available Resources then the Sensor's IPS
policy is automatically applied to those Sensor resources.
Notes:
•
Consider a scenario illustrated by the diagram. The admin domain, AD is assigned the IPS
policy - P1. It has Sensor 1 under it and a child admin domain named, CAD.
•
CAD is assigned the IPS policy P1. Sensor 1 is assigned the IPS policy P2. The interface 1A-1B is
assigned the IPS policy P3.
•
The subinterface VLAN10 is assigned the IPS policy P4.
•
The interface 2A-2B of Sensor 1 is allocated to CAD. This is assigned IPS policy, P5.
•
VLAN20 is a subinterface of 2A-2B and is assigned a policy P6.
•
In the Assignments window of P3, if you move 1A-1B from Selected Resources to Available Resources, P2
is applied to this interface. Similarly, if you move VLAN10 for P4, then P2 is applied to this
subinterface. That is, these resources fallback to the Sensor's policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
283
12
Working with IPS policies
How to manage IPS policies
7
•
Similarly, if you move 2A-2B and VLAN20 from Selected Resources to Available Resources in the
corresponding policies, the IPS policy P1 is applied. That is, these resources fall back to the IPS
policy of the domain to which they are allocated.
•
If any resource has a local IPS policy customization and you remove this resource from Selected
Resources to Available Resources in the corresponding policy, the same local policy customization is
made to the policy to which it falls back. However, for this the same attacks must be present in
this fallback IPS policy as well.
Do a configuration update for the corresponding Sensors to enforce the policy.
Configuration of attack compilation
Attack compilation page enables you to specify the type of attack definitions to be included in the IPS
Policies for a specific Sensor.
To access the Attack Compilation page:
1
Click the Devices tab.
4
Select the device from the Device drop-down
list.
2
Select the domain from the Domain
drop-down list.
5
Select Troubleshooting | Attack Compilation.
3
On the left pane, click the Devices tab.
You can select the following types of attack definitions for the Sensor:
•
Default McAfee Attacks (from the Signature Set)
•
Custom Attacks McAfee Format. These are the McAfee Custom Attacks that you defined or received
from McAfee.
•
Custom Attacks -Imported Snort Rules. These are the Snort Custom Attacks that you imported into
or created in the Manager.
Use Bulk Edit for IPS policy
Before you begin
You have opened the Attack Definitions tab for the IPS Policy that you want to edit. To go to
the IPS Policy, click Policy and select the Domain. Then go to Intrusion Prevention | IPS Policies.
The Bulk Edit option enables you to select and edit multiple attack definitions at once. This operation is
useful for configuring the same responses for multiple attacks at once, thus reducing overall
configuration time.
284
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
12
Task
1
Select the required attacks in the Attack Definitions tab.
Figure 12-7 Bulk Edit option
McAfee Network Security Platform 8.1
IPS Administration Guide
285
12
Working with IPS policies
How to manage IPS policies
2
Right-click and select Bulk Edit.
The Bulk Edit for Selected Exploit Attacks window opens.
Figure 12-8 Bulk Edit for Selected Exploit Attacks window
To bulk edit attacks at the policy level, select Bulk Edit, Customize, and Enable Attack. The other fields
in the Bulk Edit for Selected Exploit Attacks window are displayed only after you enable the attacks at the
policy level.
3
(Optional) Select the Customize Severity for all selected attacks from the drop-down list.
If there are multiple attacks with different severities, respectively, this action assigns the same
severity across all selected attacks.
4
In the Sensor Response area, select the Send Alert to the Manager checkbox if required.
However, all attacks marked as "Enabled" in the "Configure Attack Detail for Attack
Category:<protocol>" table remain enabled. Note that the Logging sub-tab as well as the Notifications
area are unavailable for configuration. These areas become available once you select the Send Alert to
the Manager checkbox.
Do one of the following:
286
5
Select the required options in the Notifications area.
6
Click the Logging tab.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
7
12
Select the Logging responses you want applied to all attacks. You must click both Enable Logging and
Capture 128 Bytes checkboxes to enable both logging responses.
Figure 12-9 Logging responses selection
8
Go back to the Sensor Actions tab.
9
Select the checkboxes next to the Sensor responses you want active for all attacks.
10 Click OK at the bottom of the window. A review page displays your customizations.
Click Cancel to exit Bulk Editing without changes.
11 Click OK to confirm and save your bulk edit changes.
You are returned to the Configure Attack Detail for Attack Category window.
Add comments for an attack
The Annotate Description option allows you to add your annotations for an attack. The annotations for an
attack can be added during attack customization. This option is available in the IPS Policies, Default IPS
Attack Settings, and Reconnaissance Policies for all attack categories.
This option is not available when you bulk edit.
McAfee Network Security Platform 8.1
IPS Administration Guide
287
12
Working with IPS policies
How to manage IPS policies
Task
1
Select the attack for customization.
2
Click Annotate Desc.
Figure 12-10 Edit Attack Details For Attack window - Annotate Description option
Checking Visible to Child Admin Domains options allows child domains to view comments added at the
parent level. The parent domain cannot view comments added by child domain.
3
Select the option for Annotations of Parent Admin Domains.
•
Append to: Adds new comments to the existing comments of the parent domain (default).
•
Override: New annotations added are displayed. Parent domain annotations are not displayed.
As child domains cannot edit policies created by parent domains, child domains can create own
policies or clone policies. Similarly, child domains are not allowed to edit parent annotations but can
append or override them.
4
Enter your comments in the Add Comment for Attack Description area.
The maximum number of characters you can enter is 1024 characters.
5
Click Save.
Tasks
•
Append comments to parent domain on page 288
•
Override the parent domain annotations on page 289
Append comments to parent domain
The Append to option adds the new annotations to the existing annotations. Child domains are allowed
to add additional annotations to that of the parent. The child domain can view the parent annotations,
but is not allowed to edit the annotations.
Appended annotations are displayed only in the domain created and its child domains. The parent
domain cannot view the child annotations.
288
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
12
Task
1
Select the attack for customization.
2
Click Annotate Description.
3
Select Append to from the Annotations of Parent Admin Domain list.
4
Enter new annotations in the Add Comment for Attack Description.
5
Click Save.
Your comment appears below the parent annotations.
Figure 12-11 Annotate Attack Description for Admin Domain dialog
Override the parent domain annotations
Child domains are allowed to override parent annotations. The Override option displays only the new
annotations added in the domain. Parent annotations are not displayed.
Child annotations are displayed only in the domain created and its child domains.
To override the parent domain annotations, do the following:
Task
1
Select the attack for customization.
2
Click Annotate Description.
3
Select Override from the Annotations of Parent Admin Domains list.
McAfee Network Security Platform 8.1
IPS Administration Guide
289
12
Working with IPS policies
How to manage IPS policies
4
Enter new annotations in the Add Comment for Attack Description.
5
Click Save.
Figure 12-12 Annotate Attack Description for Attack dialog — Override option
290
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
12
How to view user annotations
Your annotations are also displayed in the Attack encyclopedia.
Figure 12-13 Attack information & Description page
Click Attack Description to view your annotations under User Comments section of the Attack encyclopedia.
Customize attacks across policies
The Default IPS Attack Settings (formerly Global Attack Response Editor (GARE)) is an attack editor that
works in concert with the policy and bulk editors. This editor, available only in the root admin domain,
enables you to edit an attack definition's response once and have that modification apply across all
policies that contain that attack definition, rather than having to find all policies that use a particular
attack, and then modify the response on each of those policies one at a time. This includes the attack
instances in the policies of a child domain. All attack response attributes can be customized (for
example, Sensor response actions, logging, exception objects, notifications).
Default IPS Attack Settings displays the attacks that match the parameters in your selected rule set — all
exploit attacks are categorized by protocol (that is, the application protocol they affect). From here,
you can drill down to customize individual attack settings such as exception objects, Sensor
responses, and notifications to be sent. This customization is optional, but McAfee recommends that
you become familiar with them.
McAfee Network Security Platform 8.1
IPS Administration Guide
291
12
Working with IPS policies
How to manage IPS policies
Using Default IPS Attack Settings, you can modify exploit, DoS, and reconnaissance attack definitions.
Task
1
In the Manager, click Policy and select the root admin domain.
2
Select Intrusion Prevention | Advanced | Default IPS Attack Settings | Exploit Attacks.
•
Protocol— The protocols that were chosen as a result of the rule set configuration. Attacks are
grouped under the application protocol which they affect.
•
No. of Available Attacks— Number of attacks for each protocol.
•
No. of Enabled Attacks— Number of attacks enabled for detection. All attacks are enabled by default.
The No. of Available Attacks and No. of Enabled Attacks may display a discrepancy if an enabled attack is
disabled during user customization.
Figure 12-14 Exploit Attacks area
To edit DoS or reconnaissance attacks, click the corresponding tabs.
3
View the exploit attacks for a protocol by selecting a row and clicking View / Edit.
The Attack Definitions page opens. You can sort the attacks by clicking any of the following topic
columns:
•
Attack Enabled— Enforcement status of attack. A check mark in the Attack Enabled field means the
attack is actively being sought.
From 8.0, all the ARP attacks are disabled by default for fresh installation of Manager. But when
you upgrade your Manager from a lower version to 8.0, the ARP attacks are enabled by default.
•
Alert Enabled— Alert status of attack. A check mark in the Alert Enabled field means that an alert
is raised for this attack.
From 8.0, all the ARP alerts are disabled by default for fresh installation of Manager. But when
you upgrade your Manager from a lower version to 8.0, the ARP alerts are enabled by default.
292
•
Attack Name— The Network Security Platform-designated name for the attack.
•
NSP Attack ID— The Network Security Platform-designated ID for the attack.
•
Severity— The potential impact represented by the attack.
•
SID— The Snort rule ID for Snort Custom Attacks.
•
Customized— A check denotes that an attack has been user-customized.
•
Packet Logging— A check denotes that an attack has packet logging enabled.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
12
•
Sensor Actions— Type of Sensor action performed on an attack followed by the level at which the
Sensor action was indicated.
•
Blocking— This refers to SmartBlocking, and is applicable to 6.1 Sensor versions and later. In
SmartBlocking, attacks are blocked based on the Benign Trigger Probability (BTP) value of
attack signatures which trigger the attack.
McAfee Network Security Platform 8.1
IPS Administration Guide
293
12
Working with IPS policies
How to manage IPS policies
•
Notifications— A check denotes that an attack has notifications enabled followed by the level at
which the notification was indicated.
•
Sensor Software Versions— Two columns with the current and previous Sensor software versions are
either checked or unchecked indicating whether the attack relates to the current or previous
software versions or both.
Figure 12-15 Configure Attack Details for Attack Category window
294
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
4
12
Do one of the following:
•
View/customize a single attack's details by selecting a row and clicking View / Edit. Continue to
Step 5 for attack customization.
•
Customize multiple attacks at once by selecting multiple rows and clicking Bulk Edit. The bulk edit
feature enables you to select and edit multiple attacks at once, which is useful for setting
multiple responses at one time.
•
Select the drop-down list at the top right corner of Configure Attack Detail page. You can filter the list
of attacks based on the following criteria:
Figure 12-16 Exception Object — drop-down list
1
All Selected Attacks— Displays all attacks without any filter.
2
Only Attacks Eligible for Quarantine— Displays a list of attacks that are eligible for Quarantine.
3
Only Attacks Recommended for Blocking— Displays attacks that are recommended for blocking by
McAfee.
4
Only Attacks Recommended for SmartBlocking— Displays attacks that are recommended for
SmartBlocking by McAfee.
5
Advanced Search— Allows you to search for attacks using parameters such as attack name,
impacted applications, reference ID such as CVE or BugTraq, new attacks, and attacks based
on the device family.
McAfee Network Security Platform 8.1
IPS Administration Guide
295
12
Working with IPS policies
How to manage IPS policies
5
View the attack you selected for customization. To customize the attack at the policy level, click the
Customize checkbox next to the description and make your changes.
At any time during attack customization, you can clear all changes you have made by clicking Clear
Custom at the bottom of the dialog box.
Figure 12-17 Edit Attack Details For Attack window
296
•
Attack Name— Assigned by McAfee.
•
Customize Severity— Potential impact level of the attack. For per-attack customization, see Step 6.
•
Attack Desc.— Click to read a detailed description of the attack.
•
Annotate Desc.— Click to add your annotations for an attack in the attack encyclopedia.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to manage IPS policies
•
12
Sig. Desc.— Click to open a new window listing the signatures used to detect the attack. Click Done
to close the new window.
Figure 12-18 Display Signatures for Attack dialog
6
•
Benign Trigger Probability— Probability that the signature will raise a false positive.
•
Target— Origin of flow; attack was either client or server initiated.
•
Applications Impacted— Lists the applications affected by the attack.
•
Blocking Type— Indicates whether only the attack packet is blocked or the entire flow is blocked.
•
Category— The category to which the attack belongs. Examples are exploit, malware, and policy
violation.
•
Sub-category— The sub-category to which the attack belongs. Examples are audit, back door, and
brute force.
(Optional) Change the Severity by toggling the drop-down list if you want the attack to be of a higher
or lesser priority.
Each attack has a preconfigured severity that relates to the negative impact of the attack in your
network. Changing the attack severity is not recommended.
McAfee Network Security Platform 8.1
IPS Administration Guide
297
12
Working with IPS policies
Attack descriptions
7
In the Configure Attack Detail window, you can also configure Sensor Actions and Logging.
8
Click OK.
9
Click Done in the Configure Attack Details for Attack Category page and then Save in Default IPS Attack Settings.
10 Push the configuration changes to the corresponding Sensors.
Attack descriptions
Every attack definition provided by McAfee includes an attack description. The information in this
description is designed to give reference to what the attack does and how to defend against the attack
in the future.
Attack descriptions can be accessed from a number of areas:
•
Policy — during policy viewing/creation. Includes all Exploit, DoS, and Reconnaissance attacks.
•
Threat Analyzer — within the details of a detected attack.
•
Network Security Platform KnowledgeBase — all entries within the Attack Encyclopedia.
When you click an Attack Description button, an HTML file opens in an Internet Explorer browser window.
Figure 12-19 Attack description example
The Attack Information & Description fields are as follows:
298
•
Name — Network Security Platform-designated name for an attack.
•
Vulnerability Type — type of inherent system flaw that can be exploited by attackers.
•
Impact Category — type of impact that it can have on a system.
•
Impact Subcategory — type of inherent system flaw that can be exploited by attackers.
•
Severity — malicious impact potential of the attack. The values are high, medium, and low.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to export and import policies
12
•
Benign Trigger Probability — The benign trigger probability is the chance that the signatures for an
attack may trigger a false positive.
•
Description — attack definition and conditions.
•
Possible Effects — the impact if the attack is successful.
•
Recommended Solution — available workarounds and patches.
•
Platforms Affected — systems and/or software directly affected by the attack.
•
Reference — Network Security Platform supports multiple standards and sources for finding
information on known attacks. Cross-referencing a Network Security Platform attack name with a
CVE name, BugTraq ID, or other link can assist your analysis of known attacks and vulnerabilities.
•
•
Network Security Platform ID — globally unique attack ID within the Network Security Platform.
•
Last Rev Date — last date attack information was updated.
•
CVE — The Common Vulnerabilities and Exposures (CVE) name related to an attack. CVE
maintains a list of standardized names related to publicly known vulnerabilities and security
exposures. Refer to www.cve.mitre.org. A CVE name such as "CVE-1999-0001" is called an
entry, denoted by "CVE" at the beginning of the name. An entry is a vulnerability or exposure
that has been accepted by the CVE Editorial Board. A CVE name such as "CAN-2001-0002" is
called a candidate, denoted by "CAN" at the beginning of the name. A candidate is a
vulnerability or exposure that is "under consideration for acceptance into CVE." A CVE name has
three fields — entry status, year of entry, and entry number during the year. Thus, if a CVE
name reads "CVE-2000-0005," the vulnerability/exposure was the fifth accepted entry in the
year 2000. Between candidacy and entry, a CVE entry will most likely change numeric ID along
with the change from CAN to CVE-. Thus, CAN-2001-0023 may be accepted in the year 2002
and thus read — "CVE-2002-0002.".. BugTraq: ID of attack as listed in the BugTraq database.
Refer to http://online.securityfocus.com/.
•
Microsoft — ID of attack as listed in the Microsoft Security Bulletin.
•
Links — additional information sources.
User Comments — Any comments that you have entered for the attack description.
How to export and import policies
Network Security Platform gives you the ability to create/clone a policy on a non-production Manager
server, then import the new policy/exception object to your production Manager. Also, you can export
custom policies/filters from your Manager to a non-production machine for editing or other purposes.
•
Exporting policies — Export policies from your Manager to your client.
•
Importing and comparing policies — Import policies to your Manager.
Export policies
Policy export enables you to save one or more custom (created/cloned) IPS policies and
reconnaissance policies from your Manager server to your client. This is effective for archiving as well
as transferring a policy from a test Manager environment to your live environment. For example, you
log in to your test Manager from a client and create a policy. After creation, you export the policy to
your client. You then log into your live Manager from the client and import the policy for active use.
Policies of the Central Manager are not available for export.
McAfee Network Security Platform 8.1
IPS Administration Guide
299
12
Working with IPS policies
How to export and import policies
Task
1
In the Manager, click Policy and select the required Domain.
2
Select Intrusion Prevention | Advanced | Policy Export | IPS and Reconnaissance.
3
Select the policies you want to export from the IPS Policies and Reconnaissance Policies tables.
Default IPS Attack Settings corresponds to the Default IPS Attack Settings from the root admin domain.
Figure 12-20 Export IPS and Reconnaissance policies
4
Click Export when you have selected the wanted policies.
5
Browse to the location on your client where you want to save the exported file.
6
Verify successful export by checking the destination for the exported file. The policy file is saved as
an XML file, and it contains all of the policies you selected for export. Thus, if you selected two
policies for export, both policies are saved in the same file.
Although this feature outputs an XML file, this file is NOT intended for reading or editing. Any
manipulation of this file besides regular copying from/to different media will result in possible import
failure.
How to import and compare policies?
You can compare and add a policy to the Manager from a different location on your network or from a
storage device.
Visibility rules, as they pertain to a policy being available to a child domain, apply to imported policies.
Thus, for any custom (created or cloned) policy you import, if you unchecked the Visible to Child Admin
Domains checkbox during creation, the imported policy will only be visible in the Admin Domain.
Importing and comparing policies involves the following:
300
•
Selecting a policy to import
•
Comparing policies before importing
•
Completing the policy import
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
How to export and import policies
12
Import IPS and reconnaissance policies into the Manager
Before you begin
Make sure the XML file containing the exported policies is not open or is being imported by
some other user.
You can import the XML file containing the exported IPS and reconnaissance policies into a Manager.
Notes:
•
The version of the Manager from which you exported the policies and the current version of the
Manager must be an exact match.
•
You should not have modified contents or the properties of the XML file.
•
If the same policy exists in the Manager, then you can import only if there is a difference and only
at the admin domain of the existing policy. The Manager checks if the same policy exists based on
the policy name mentioned inside the XML file and not based on the name of the XML file.
Task
1
In the Manager, click Policy and select the required Domain.
2
Select Intrusion Prevention | Advanced | Policy Import | IPS and Reconnaissance.
3
Click Choose File to locate the XML file you want to import.
4
Click Next to download the file to the Manager.
Figure 12-21 View the differences and import the policy
5
Select the policy you want to import and click Difference to view the differences between the current
policies in the Manager and the policies you want to import.
The Policy Diff page appears. This page provides a read-only listing of differences between two
different Network Security Platform policies (including differences between a single policy
configured for Inbound and Outbound). During the policy import process, the Policy Diff page enables
McAfee Network Security Platform 8.1
IPS Administration Guide
301
12
Working with IPS policies
How to export and import policies
you to select a policy stored on the Manager server to compare against the policy you are currently
importing. The utility then displays differences between the two files.
Attributes having the same value in both policies are not displayed.
Figure 12-22 Policy Diff window — Snapshot view
The diff information between 2 policies is presented in 3 different views. Each view differs in the
depth of the diff information displayed.
•
Snapshot — This view displays the differences at a high level; this view indicates the differences
within the 6 logical groups.
•
Summary — This view displays all details, except attack difference details in the Exploit, Threshold
and Statistical sections, which do display in Detail view.
•
Detail — This view displays all data differences, including attack details.
In all three views, the data displays in a standard Windows folder structure and can expand/
collapse at all levels. Both horizontal and vertical scroll bars are synchronized; scrolling in one
policy window scrolls the other window. The state of a view is not maintained when you navigate to
a different view and return; instead the state is reset to the initial state of the view.
Figure 12-23 Policy Diff window — Detail view
The imported policy displays on the left; the existing policy displays on the right. The number of
differences for a particular item in the policy is shown in red text and enclosed in parentheses (for
example, (2) is displayed if you have two differences). A cross mark (X) signifies that a part of the
policy present in the opposite side of the window is missing from the policy.
302
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Assign IPS and reconnaissance policies at the admin-domain level
12
There is a limit on the number of differences to be displayed. If the diff count is greater than 100,
only the first 100 attacks are displayed (with diff details) in the utility. This indicates that there are
more than 100 differences in that section.
If the outbound policy is configured for one of the policies, only the name of the policy is displayed
and not the outbound policy details. Only exception object names are compared in the utility;
exception object definitions are not compared, as they are not part of the Policy definition.
The attacks which are in the policy export file and not found in the imported signature set, will
always be displayed in Policy Diff information while importing the policy export file to the Manager.
Close the Policy Diff window to return to the Import Policy Difference Status page.
6
Select the policies that you want to import and click Save.
The imported policies are listed in the IPS Policies page and Reconnaissance Policies page
respectively.
Assign IPS and reconnaissance policies at the admin-domain
level
Sensor allows very granular policy application and enforcement: multiple IPS and DoS policies can be
enforced on a single port or port pair. For example, suppose you are a super user at the root admin
domain level, and you deploy a single Sensor. You edit the details of your root domain and decide to
keep the Default Inline IPS policy that is applied by default upon Manager installation. When you add the
Sensor, the Default Inline IPS policy is inherited from the root domain and applies to the Sensor and all of
the Sensor's interfaces by default. If you want to apply a different IPS policy, you can easily re-assign
policies applied to the Sensors and their interfaces/subinterfaces within the current administrative
domain or child administrative domains.
You can quickly find and re-assign policies applied to multiple Sensors and their resources (interfaces/
subinterfaces) without having to search extensively in Network Security Platform. You can filter your
search results by policies (for example, IPS policy/ reconnaissance policy), or Sensors. From the
search results, you can select the resources and re-assign policies, as required.
You can re-assign reconnaissance policy only to Sensors, and not to Sensor interfaces/subinterfaces.
Tasks
•
Assign an IPS policy from the IPS Policies page on page 281
•
Assign reconnaissance policies to Sensors from the Reconnaissance Policies page on page
307
Assign an IPS policy from the IPS Policies page
Before you begin
Make sure the IPS policies that you want to assign to Sensor resources are available.
In McAfee® Network Security Platform, IPS policies are enforced at the interfaces and subinterface, not
at the Sensor level. Since the Sensors are multi-port and thus multi-interface and multi-subinterface,
this allows multiple policies to be enforced within a single Sensor rather than a single catch-all policy.
Compared to some other IPS products, this is like having several Sensors in one box.
McAfee Network Security Platform 8.1
IPS Administration Guide
303
12
Working with IPS policies
Assign IPS and reconnaissance policies at the admin-domain level
When you create an admin domain, you can select the default IPS and reconnaissance policies for that
admin domain. When you add a Sensor to that domain or allocate interfaces and subinterfaces, these
policies are applied to those Sensor resources by default. You can assign different policies to those
Sensor interfaces and subinterfaces through the corresponding Protection Profile page. An alternative
method is to assign an IPS policy from the IPS Policies page itself. This is especially useful when you
want to define an IPS policy and also quickly assign it to Sensor interfaces and subinterfaces.
Task
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | IPS Policies
4
Click the Assigned Resources value of the policy that you want to assign.
The Assignments window displays.
304
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Assign IPS and reconnaissance policies at the admin-domain level
5
12
Assign the IPS policy to the required interfaces and subinterfaces.
Figure 12-24 Assignments window
Table 12-2 Option definitions
Option
Definition
Search Resources
To filter the list of available resources, enter a string that is part of the Available
Resources.
Available Resources Lists the interfaces and subinterfaces of the Sensors in the admin domain. The
Sensor resources to which you have already assigned this IPS policy are
displayed under Selected Resources.
In case of Sensors in failover, the ports used for interconnection of the Sensors
are not displayed. If you assign an IPS policy to an interconnect port, the
assignment is automatically removed when you create the failover pair.
Select a resource and click
Current Policy
to move it to Selected Resource.
The IPS policy that is currently assigned to a resource. To replace that policy
with the policy that you are currently assigning, move the resource to Selected
Resource.
Selected Resources Lists the Sensor resources to which you have assigned the selected IPS policy.
6
Reset
Reverts to last saved configuration.
Save
Saves the changes to the Manager database.
Cancel
Closes the Assignments window without saving the changes.
If you move a Sensor resource from Selected Resources to Available Resources then the Sensor's IPS
policy is automatically applied to those Sensor resources.
Notes:
McAfee Network Security Platform 8.1
IPS Administration Guide
305
12
Working with IPS policies
Assign IPS and reconnaissance policies at the admin-domain level
7
306
•
Consider a scenario illustrated by the diagram. The admin domain, AD is assigned the IPS
policy - P1. It has Sensor 1 under it and a child admin domain named, CAD.
•
CAD is assigned the IPS policy P1. Sensor 1 is assigned the IPS policy P2. The interface 1A-1B is
assigned the IPS policy P3.
•
The subinterface VLAN10 is assigned the IPS policy P4.
•
The interface 2A-2B of Sensor 1 is allocated to CAD. This is assigned IPS policy, P5.
•
VLAN20 is a subinterface of 2A-2B and is assigned a policy P6.
•
In the Assignments window of P3, if you move 1A-1B from Selected Resources to Available Resources, P2
is applied to this interface. Similarly, if you move VLAN10 for P4, then P2 is applied to this
subinterface. That is, these resources fallback to the Sensor's policy.
•
Similarly, if you move 2A-2B and VLAN20 from Selected Resources to Available Resources in the
corresponding policies, the IPS policy P1 is applied. That is, these resources fall back to the IPS
policy of the domain to which they are allocated.
•
If any resource has a local IPS policy customization and you remove this resource from Selected
Resources to Available Resources in the corresponding policy, the same local policy customization is
made to the policy to which it falls back. However, for this the same attacks must be present in
this fallback IPS policy as well.
Do a configuration update for the corresponding Sensors to enforce the policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Assign IPS and reconnaissance policies at the admin-domain level
12
Assign reconnaissance policies to Sensors from the
Reconnaissance Policies page
Before you begin
Make sure the reconnaissance policies that you want to assign to the Sensors are available.
Although IPS policies are not customizable at the Sensor level, reconnaissance attack enforcement is.
Reconnaissance attacks, such as port scans and host sweeps, are customized at the Sensor level
because these types of attacks are often spread out across a network and are not easily detected in
the traffic monitored by a single interface. By enforcing the reconnaissance detection at this level, a
broader view of network activity can be achieved.
When you create an admin domain, you can select the default IPS and reconnaissance policies for that
admin domain. When you add a Sensor to that domain, these policies are applied to it by default. You
can assign a different reconnaissance policy to that Sensor from its Protection Profile page. An alternative
method is to assign the reconnaissance policy from the Reconnaissance Policies page itself. This is
especially useful when you want to define a reconnaissance policy and also quickly assign it to a
Sensor.
Task
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | Reconnaissance Policies.
4
Click the Assigned Resources value of the policy that you want to assign.
McAfee Network Security Platform 8.1
IPS Administration Guide
307
12
Working with IPS policies
Assign policies for a Sensor
5
Assign the Reconnaissance policy to the required Sensors.
Figure 12-25 Assignments window
Table 12-3 Option definitions
Option
Definition
Search Resources
To filter the list of available resources, enter a string that is part of the Available
Resources.
Available Resources Lists the Sensors in the admin domain. The Sensors to which you have already
assigned this reconnaissance policy are displayed under Selected Resources.
Select a Sensor and click
Current Policy
to move it to Selected Resource.
The reconnaissance policy that is currently assigned to a Sensor. To replace that
policy with the policy that you are currently assigning, move the resource to
Selected Resource.
Selected Resources Lists the Sensors to which you have assigned the selected reconnaissance policy.
If you move a Sensor from Selected Resources to Available Resources for a
reconnaissance policy, then the corresponding admin domain's reconnaissance
policy is applied to that Sensor by default. That is, the Sensor's reconnaissance
falls back to the admin domain's reconnaissance policy.
6
Reset
Reverts to last saved configuration.
Save
Saves the changes to the Manager database.
Cancel
Closes the Assignments window without saving the changes.
Do a configuration update for the corresponding Sensors to enforce the policy.
Assign policies for a Sensor
You can assign the policies such as the IPS, Reconnaissance, and Firewall policies at the Sensor level.
These policies are applied to all the resources of that Sensor. If applicable, as in case of IPS and
Firewall policies, you can override the assigned policies at the interfaces and subinterfaces.
308
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Assign policies for a Sensor
12
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select Policy | Protection Profile.
Figure 12-26 IPS Sensor tab
6
Select the Baseline IPS Policy in the IPS Policy section to select an IPS policy.
You can also assign the Reconnaissance Policy and the Firewall Policy. For information on these policies,
see the corresponding sections.
7
Click Save.
A message displays that policy change requires a configuration update of the Sensor.
8
Click OK, and then update the configuration change to the Sensor.
See also
Passive Device Profiling on page 344
Simulated Blocking on page 259
McAfee Network Security Platform 8.1
IPS Administration Guide
309
12
Working with IPS policies
Assign IPS policies to interfaces and subinterfaces
Assign IPS policies to interfaces and subinterfaces
An interface node in the Manager represents an interface (a single physical port, peer ports, or an
interface group) on a particular Sensor. The number of interface nodes displayed depends upon the
type of Sensor. Full-duplex Tap and Inline modes require two physical ports, and each mode uses
these two ports to form a single logical interface. Therefore, all configuration and policy decisions are
made at a logical interface level. SPAN ports are represented by individual interface nodes.
Interfaces can be allocated to child domains for specialized management.
After a new Sensor is installed, a policy is inherited from the admin domain and enforced on all Sensor
interfaces. In large deployments or ones that have a significant number of policies configured in the
Manager, it can take a long time to download the signature sets and apply the policy changes to the
Sensors. You define policies at the admin domain level using the IPS Policy Editor. This becomes your
Baseline Policy. When two or more Sensor interfaces protect similar types of traffic, you can assign the
same baseline policy to each of these interfaces, and optionally customize specific attack settings per
interface, as required. This helps in minimizing scalability issues, and enhances the overall policies
management process in the Manager. The baseline policy is assigned to the interface and now
functions as a starting point for the local attack settings.
Inbound refers to any traffic destined for the internal network from an external source. Outbound refers
to any traffic that originated from your internal network.
Each subinterface created within an interface can have a specific IPS policy applied. For example, if
you have created three subinterfaces using VLAN tags, you can apply individual policies different from
that of the parent interface to each of the three subinterfaces, respectively.
When you create a subinterface, you can specify an IPS policy or simply inherit the IPS policy of the
parent interface. This policy can be changed at any time per subinterface. The procedure to apply IPS
policies to subinterfaces is similar to that of interface. However, note this important point regarding
how the policies are enforced. If you apply a policy to a subinterface that is different than the
inherited policy, the policy enforced at the interface level protects all traffic not specific to the
subinterface. That is, the IPS policy of the subinterface exclusively protects all of the traffic that meets
the criteria of the subinterface, which is typically any specified CIDR-based network or VLAN-tagged
traffic flowing through the parent interface. All other traffic monitored by the interface is thus subject
to the applied policy of the interface.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select IPS Interfaces | <interface or sub-interface name> | Protection Profile.
6
Select the Baseline IPS Policy and click Save.
7
Update Sensor configuration.
You must assign an alternate policy for a Sensor's interfaces/subinterfaces in cases where the
original policy needs to be deleted. For example, you have created an IPS policy called Custom1. You
apply it to interfaces 1B, 2A, and 4B on a Sensor. After some time, you determine Custom1 does not
work effectively, and you want to delete it. The Manager will not allow you to delete a policy that is
currently enforced. You have to change the policy of each Sensor resource where the custom policy
is applied before deleting the custom policy itself.
310
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Assign IPS policies to interfaces and subinterfaces
12
Tasks
•
Customize Local IPS Policy on page 311
•
Scenario: Apply different policies to multiple subinterfaces on page 312
Customize Local IPS Policy
The currently applied IPS policy of an interface is termed as its Baseline IPS policy. You can customize
this Baseline IPS policy only for this interface. Such a customized IPS policy is referred to as the Local
IPS policy. The initial attack settings are inherited from the assigned baseline policy, yet
customizations to the local policy affect this interface only.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select IPS Interfaces | <interface or sub-interface name> | Protection Profile.
Baseline IPS Policy indicates the currently assigned IPS policy.
Figure 12-27 Baseline IPS Policy option
6
Click Use a Local Policy.
7
From Local Policy Actions drop-down list, select Edit.
8
Click Go to customize the attacks. The Attack Definitions page opens. Set the correlation method for
the attack.
9
Click the Attacks tab. In the Attack Name list right-click one or more attacks you want to customize and
select Edit/Bulk Edit.
The Edit Attack Detail for Attack page opens.
10 Customize your attack by enabling the following Edit options:
•
Customize
•
Enable Attack
•
Customize Severity
11 Click OK. You can view the customized attacks under the Customized tab.
12 Click Save. The Summary page opens.
McAfee Network Security Platform 8.1
IPS Administration Guide
311
12
Working with IPS policies
Assign IPS policies to interfaces and subinterfaces
13 Click Finish to save your changes.
14 Under Local IPS Policy field, you can view the following options in the Local Policy Actions field:
•
Edit - Allows you to make changes to the local IPS policy
•
Reset - Resets the customizations to the local attack definitions.
•
Merge - Merges the local policy with the baseline policy
Figure 12-28
Options enabled after customization
15 Select Reset and click Go to reset the customizations to the local attack definitions. A warning
message is displayed. Click OK to confirm.
16 A Reset Successful message dialog opens. Click OK to confirm.
17 You can select Merge and click Go to merge the local policy with the baseline policy. A warning
message is displayed. Click OK to confirm.
If you click the integer value (if greater than 0), you can automatically go into edit mode with the
customized attacks showing in the foreground.
18 A Success dialog opens to indicate the successful merge. Click OK to confirm.
19 After a successful merge, again the Number of Attacks Customized Locally field shows the value as "0". You
can only view the Edit option now under Local Policy Actions field.
You can customize the Local IPS Policy in both the interface and subinterface levels.
20 Do a configuration update for the corresponding Sensor for the changes to take effect.
Scenario: Apply different policies to multiple subinterfaces
Multi-port Sensors support multiple applied IPS policies for interfaces and subinterfaces. This is
particularly useful if you have segmented your network traffic by VLAN tags or CIDR addressing. For
this scenario, the sample network has been segmented by CIDR addressing. Your Sensor monitors
traffic to three networks from an aggregation point. By using Network Security Platform's multiple
policy functionality, you can apply appropriate policies to individual networks, thus tuning out alerts for
traffic rarely seen in those network segments. This "tuning out" dramatically reduces the number of
alerts you see, thus positively affecting your total cost of ownership of a Network Security Platform
solution.
312
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Protection profile management at the interface level
12
Task
1
You designate port pair 1A-1B to be a CIDR interface.
The Default Inline IPS policy was inherited from the admin domain and is enforced across the entire
interface.
2
3
You add three CIDR network addresses to your interface:
•
192.168.0.0/24: multiple file servers
•
192.168.1.0/24: multiple file servers
•
192.168.2.0/24: multiple Windows servers
You create a subinterface, File_Servers, to protect networks 192.168.0.0/24 and 192.168.1.0/24
with a more appropriate policy. You create a File Server policy to protect File_Servers.
The name File_Servers is used instead of a generic name such as Sub-interface1 because a unique
name describing the subinterface environment is more effective for later identification.
4
You create another subinterface, Windows_Servers to protect 192.168.2.0/24 with a more
appropriate policy. You create a Windows Server policy to protect Windows_Servers.
All interface traffic through port pair 1A-1B that is not a part of the two subinterfaces is protected
by the Default Inline IPS policy. The File Server policy is most effective for File_Servers because
both networks consist of multiple file servers, and the File Server policy is specifically tuned to
known file server traffic elements. In the same way, the Windows Server policy is most effective for
Windows_Servers because this policy is specifically tuned for Windows server traffic. Either of these
policies can be cloned and customized, for example, to remove attacks that may be generating
false positives and/or to set an automatic response upon detection of specific attacks.
Protection profile management at the interface level
This page can be used to customize the policies as well as to configure the protection options at the
interface level.
Managing policies
In large deployments or ones that have a significant number of policies configured in the Manager, it
can take a long time to download the signature sets and apply the policy changes to the Sensors. You
define policies at the admin domain level using the IPS Policy Editor. This becomes your Baseline
Policy. When two or more Sensor interfaces protect similar types of traffic, you can assign the same
baseline policy to each of these interfaces, and optionally customize specific attack settings per
interface, as required. This helps in minimizing scalability issues, and enhances the overall policies
management process in the Manager. The baseline policy is assigned to the interface and now
functions as a starting point for the local attack settings.
Managing protection options
You can also configure the protection options here.
Inbound refers to any traffic destined for the internal network from an external source. Outbound
refers to any traffic that originated from your internal network.
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
McAfee Network Security Platform 8.1
IPS Administration Guide
313
12
Working with IPS policies
Protection profile management at the interface level
3
On the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select IPS Interfaces | <interface name> | Protection Profile to customize the policies or to configure the
protection options.
Figure 12-29 Protection Profile sub-tab
The IPS, Firewall, and other policies as well as the features under Protection Options section can be
configured from the subinterface level also.
314
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
The IPS Sensor interface node
12
See also
Advanced botnet detection on page 7
Advanced Traffic Inspection on page 11
Protecting your web application servers on page 649
HTTP response scanning on page 658
IP Reputation on page 11
Layer 7 data collection on page 11
Passive Device Profiling on page 344
Simulated Blocking on page 259
Inspecting X-Forwarder-For header information on page 660
Protection options at interface level
You can enable the inbound and outbound traffic options at the interface level.
Inbound traffic is that traffic received on the port designated as "Outside" (that is, originating from
outside the network) in Inline or Tap mode. Typically, inbound traffic is destined to the protected
network, such as an enterprise intranet. Outbound refers to any traffic that originated from your
internal network.
Outbound traffic is that traffic sent by a system in your intranet, and is on the port designated as
"Inside" (that is, originating from inside the network) in Inline or Tap mode.
When GTI participation is enabled, the IP reputation is applicable for every connection but it is used
differently for inbound and outbound connections:
•
For outbound connection – When GTI reports destination host as malicious, then a "GTI: High Risk
External IP Detected" attack is raised. This attack can be configured for blocking. The external
malicious host reputation is then cached and all connections to that host are blocked.
•
For inbound connection – When GTI is enabled and Connection Limiting rules are configured, you
can block the malicious traffic received on the inbound connections. For example, you can deploy a
Sensor in front of a web server, and enable GTI along with Connection Limiting rules to limit access
to the server and prevent DoS attacks.
Select Enable Inbound? or Enable Outbound? option to enable the traffic of your choice.
The IPS Sensor interface node
The Interface-x nodes under IPS Interfaces represent an interface (a single physical port, peer ports, or an
interface group) on a particular Sensor. The number of interface nodes displayed depends upon the
type of Sensor. Interface nodes are displayed individually by default because the default monitoring
mode is SPAN mode.
Full-duplex Tap and Inline modes require two physical ports, and each mode uses these two ports to
form a single logical interface. Therefore, all configuration and policy decisions are made at a logical
interface level.
After a new Sensor is installed, a policy is inherited from the admin domain and enforced on all Sensor
interfaces. Subinterfaces are user created within this resource, and can be edited here or from the
Sub-interface-x resource node.
Interfaces can be allocated to child domains for specialized management.
McAfee Network Security Platform 8.1
IPS Administration Guide
315
12
Working with IPS policies
The IPS Sensor interface node
The navigation path to the interface nodes is as follows:
1
Click the Devices tab.
4
Select the device from the Device drop-down
list.
2
Select the domain from the Domain
drop-down list.
5
Select IPS Interfaces | <interface name>.
3
On the left pane, click the Devices tab.
The primary tasks that you can perform are customizing policies, assigning policies, and configuring
protection options.
Configuration of general interface settings
The Protection Profile page at the interface level provides options for applying the general settings of an
interface.
•
Managing policies at the interface level — Configure the policies at the interface level under
Protection Profile section; manage the protection options.
•
Managing an interface — Changing the traffic type and naming the interface; enable segmentation
of the interface by changing the traffic type to CIDR or VLAN.
•
Creating subinterfaces — Create a subinterface for policy application and traffic management.
Viewing interface details
To view the details of an interface, select an interface node under IPS Interfaces:
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
On the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select IPS Interfaces | <interface name> | Properties.
Figure 12-30 Interface detail
The dialog details are as follows:
316
•
Interface Name — Identification of ports that make up the interface. For peer ports, format is xA-xB. If
this is an interface group, multiple Sensor ports are listed. This name is user-configurable if the
traffic type is changed to VLAN or CIDR; a unique name enables easy recognition.
•
Description — Description of the interface.
•
Administrative Status — State defined by user. Enable is up, Disable is down.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Deploy pending changes to a device
12
•
Operational Status — State defined by Sensor (functional) operation. Up is working and user enabled,
Down is user disabled or a malfunction has occurred.
•
Operating Mode — The monitoring configuration of the interface.
•
Interface Type — Traffic type. Dedicated by default. Can be changed to VLAN or CIDR.
•
Applied Policy — The current enforced policy.
•
Monitoring Ports — The physical Sensor ports which comprise the interface.
Click Edit to edit the interface level settings.
Deploy pending changes to a device
When you make any configuration changes, or policy changes on the Manager, or a new/updated
signature set is available from McAfee, you must apply these updates to the devices (such as Sensors
and NTBA Appliances) in your deployment for the changes to take effect.
Note the following:
•
Configuration changes such as port configuration, non-standard ports and interface traffic types are
updated regardless of the changes made to the Sensor, interface/ subinterface.
•
NTBA configuration updates refer to the changes done in the various tabs of the Devices node.
•
Policy changes are updated on the Sensor or NTBA Appliance in case of a newly applied policy, or
changes made to the current enforced policy.
•
Signature updates contain new and/or modified signatures that can be applied to the latest attacks.
You can deploy the configuration changes to all the devices in the admin domain from the Global tab.
The navigation path for this is Devices | <Admin Domain Name> | Global | Deploy Pending Changes.
Alternatively, you can deploy the configuration changes at a device level by selecting Devices | <Admin
Domain Name> | Devices | <Device name> | Deploy Pending Changes. In this case, the Deploy Pending Changes option
is available in the menu only if the device is active.
Task
1
Select Devices | <Admin Domain Name> | Global | Deploy Pending Changes.
The Deploy Pending Changes page is displayed.
Figure 12-31 Deploy Pending Changes page
McAfee Network Security Platform 8.1
IPS Administration Guide
317
12
Working with IPS policies
Deploy pending changes to a device
The columns in the table are as follows:
2
•
Device Name — Unique name of each device
•
Last Update — Last day and time device configuration was updated
•
Updating Mode — Online or offline update mechanism selected for the device
•
Pending Changes — Summary of changes that have been made.
•
Configuration & Signature Set — A selected checkbox indicates that the device is to be updated for any
configuration change other than those related to SSL key management
•
Status— Displays the status of the Sensor during update.
Click Deploy.
The Manager processes these updates in three stages — Queued, Deploying, Completed — and
displays the current stage in the Status Column.
Figure 12-32 Configuration update
Status
Description
Queued
The Queued status indicates that the Manager is preparing to deploy updates to the
devices. If more than one device is being updated, devices are updated one at a time
until all downloads are complete. If you want to cancel the updates for certain devices,
click the X. Consider the following:
• The deployment of the configuration changes or signature file updates can be
cancelled for bulk updates only.
• Updates cannot be cancelled when deployed for individual devices.
• After you click Deploy, wait for five seconds before you start cancelling the updates for
devices.
• Once cancelled, the checkbox is deselected, suggesting that the update was cancelled.
There is no status change to indicate the cancellation of an update.
Deploying In this state, the configuration changes are applied to the devices. There is no option to
abort the update process for devices in which the deployment of updates are already in
progress. When the deployment is cancelled for any device, the item will still be
selected for future updates unless it is explicitly deselected.
Completed Shows that all the configuration changes have been updated for the devices.
3
318
Click Offline Update Files to view and export the deployment changes file to offline Sensors. The
changes can then be deployed to the Sensors manually using the CLI command window.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Import a Sensor configuration file
4
Click Refresh to refresh the page and the status of the deployment.
5
Click Clear Status to clear the status column in the UI.
12
Clearing the status does not cancel the deployment. The update process will be running in the
background.
Import a Sensor configuration file
Before you begin
The Manager from which configuration is exported and the one to which configuration is
imported must be identical. They should be of the same model, and same software version.
Both Managers must have the same admin domain hierarchy, or at a minimum, the same
admin domain hierarchy starting from the domain wherein the Sensor resides.
For example, if you exported a Sensor belonging to /My Company/Domain A, and below
Domain A, there is:
•
/My Company/Domain A/Domain B
•
/My Company/Domain A/Domain B/Domain C
The importing Sensor must reside in a domain that has the following sub-domains:
•
Domain B
•
Domain B/Domain C
McAfee recommends that the Sensor receiving the import has the same signature set as
the exporting Sensor. It is recommended that both the Managers have the same set of
policies if policies have also been exported/imported.
The Import Configuration option enables you to overwrite the current configuration on a saved (exported)
Sensor configuration file.
Importing a saved configuration is useful in a test-to-production environment where you configure
your settings on a test (non-production) Manager system, then import to a Sensor in your live
environment.
Importing is also useful in the event a Sensor fails and you replace the failed Sensor with a new
Sensor, which requires the same configuration as the previous Sensor.
Task
1
Select Devices | <Admin Domain Name> | Devices | <Device Name> | Maintenance | Import Configuration.
The <Device Name> could refer to either a Sensor.
The Import Configuration page is displayed.
2
Click Browse to locate your saved Sensor configuration.
3
Click Apply.
4
Upon completion of import, reboot the Sensor.
5
Run a Sensor report to verify settings.
McAfee Network Security Platform 8.1
IPS Administration Guide
319
12
Working with IPS policies
Export the Sensor configuration
Export the Sensor configuration
The Export Configuration feature enables you to save the configuration of a Sensor (including NTBA
Appliance configuration settings of the Sensor) into a single file for later application to the same
Sensor or another Sensor of the same model.
The Export Configuration feature helps to avoid duplication of work when it comes to configuring Sensors.
For example, if you are deploying multiple Sensors of the same model with similar configuration, you
can configure one Sensor and export its configuration to the rest. This feature is also useful if you plan
on restoring the configuration back on the same Sensor or its replacement.
You can include the following when you export a Sensor configuration. The choices vary depending on
the Sensor model:
•
Include firewall policy information — Includes firewall policy information.
•
Include Quarantine configuration — Includes Quarantine-related configuration for the Sensor and its ports
but does not include monitoring port IP addresses.
•
Include monitoring port information — Includes monitoring port information. This option is available only if
the Sensor is integrated with an NTBA appliance.
•
Include exceptions — This option exports the alert-filter-to-attack mappings configured for the Sensor,
its interfaces, and subinterfaces. Note that selecting this option exports only the exceptions
association but not the actual exceptions.
•
Include NTBA configuration — This option exports NTBA configuration set.
Task
1
Select Devices | <Admin Domain Name> | Devices | <IPS Sensor> | Maintenance | Export Configuration.
The Export Configuration page is displayed.
Figure 12-33 Configuration Export page
2
Select the configurations that you want to include in the export.
3
Click Export and save the file to a location of your choice.
Alert notification options
The Manager can send alert information to third-party repositories such as SNMP servers and syslog
servers. Further, you can configure your Sensor to forward syslog notifications directly to a syslog
server, thereby ensuring that the Sensor forwards alerts to a server other than that assigned to the
Manager.
320
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
In addition to SNMP and syslog notifications, the Manager can also be configured to notify you through
email, pager, or script of detected attacks.
For the alert notifications for the Sensor and the NTBA Appliance select Manage | <Admin Domain Name> |
Setup | Notification | (IPS/NTBA) Events.
Alert notifications are forwarded to syslog servers based on the configuration. Within the
configuration, settings notification destination form only one aspect. The Manager and Sensor send
notifications depending on the attack, the attack severity, or both.
How to view alert notification details
The Summary page for alert notification (Manage | Setup | Notification | Alerts | (IPS/NTBA) Events | Summary)
displays a summary of configured alert notification settings. The summary displays your configuration
settings made for each individual notification option.
Figure 12-34 Summary page
Forward alerts to an SNMP server
You can configure the SNMP server to which alert information for Sensor or NTBA Appliance is to be
sent.
You can configure more than one SNMP server. The SNMP Servers list in the SNMP tab displays the SNMP
servers you have configured.
Task
1
Select Manage | Setup | Notification | IPS Events | SNMP.
The SNMP tab is displayed where Enable SNMP Notification option and the configured SNMP Servers list is
displayed.
2
Select Yes against Enable SNMP Notification and click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
321
12
Working with IPS policies
Alert notification options
3
Click New.
The SNMP page is displayed.
Figure 12-35 SNMP page
4
Specify your options in the appropriate fields.
Table 12-4 SNMP - configuration options
Field
Description
Admin Domains
Specify whether this applies to the child domains as well.
IP Address
IP address of the target SNMP server. This can be an IPv4 or IPv6
address.
Target Port
SNMP listening port of the target server.
SNMP Version
The version of SNMP running on your target SNMP server. Version
options are 1, 2c, Both 1 and 2c, and 3.
Community String
Enter an SNMP community string to protect your Network Security
Platform data. SNMP community strings authenticate access to
Management Information Base (MIB) objects and functions as embedded
passwords.
Send Notification If
By attack for Sensor and The attack definition has this notification option explicitly
enabled for IPS — Forwards attacks that match customized policy
notification settings, which you must set when editing attack responses
within the Policy Editor.
By Exception object for Sensor and The following notification filter is matched for
NTBA — Sends notification for all, or based on the severity of alerts:
• Allow All — Notifies for all discovered attacks.
• Block All — Blocks notification.
• Informational severity and above — Includes all alerts.
• Low severity and above — Includes low, medium, and high severity alerts.
• Medium severity and above — Includes both medium, and high severity
alerts.
• High severity — Includes only high severity alerts.
The following fields appear only when SNMP Version 3 is selected.
322
User Name
User name for authentication.
Authoritative Engine ID (Hex
Values)
The authoritative (security) engine ID used for SNMP version 3 REQUEST
messages.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Table 12-4 SNMP - configuration options (continued)
Field
Description
Authentication Level
This specifies the authentication level and has the following categories:
• No Authorization, No Privileges — Uses User name match for authentication.
• Authorization, No Privileges — Provides authentication based on the MD5 or
SHA algorithms.
• Authorization and Privileges — Provides authentication based on the MD5 or
SHA algorithms. It also provides encryption in addition to
authentication based on the DES or AES standards.
The following fields appear only when Authorization, No Privileges is selected as Authentication Level:
Authentication Type
The authentication protocol (MD5 or SHA) used for authenticating SNMP
version 3 messages.
Authentication Password
The authentication pass phrase used for authenticating SNMP version 3
messages.
The following fields
appear only when
Authorization and Privileges
is selected as
Authentication Level:
5
Authentication Type
The authentication protocol (MD5 or SHA) used for authenticating SNMP
version 3 messages.
Authentication Password
The authentication pass phrase used for authenticating SNMP version 3
messages.
Encryption Type
The privacy protocol (AES or DES) used for encrypting SNMP version 3
messages.
Privacy Password
The privacy pass phrase used for encrypting SNMP version 3 messages.
Click Save.
The SNMP server is added to the SNMP Servers page.
Do not use a broadcast IP address (that is, 255.255.255.255) as the target SNMP server for
forwarding alerts.
Tasks
•
Modify or delete SNMP server settings on page 323
Modify or delete SNMP server settings
You can modify or delete the SNMP server settings at the Manage node.
Task
1
Select Manage | Setup | Notification | IPS/NTBA Events | SNMP.
The SNMP tab with the Enable SNMP Notification option and the SNMP Servers list is displayed.
2
Select the configured SNMP server instance from the SNMP Servers list.
3
Configure the following:
a
To edit the settings, click Edit, modify the fields as required, and click Apply.
b
To delete the settings, click Delete and click OK to confirm deletion.
McAfee Network Security Platform 8.1
IPS Administration Guide
323
12
Working with IPS policies
Alert notification options
Syslog notifications
The Sensor and Manager can independently be configured to forward alert information to a syslog
server. By default, the Sensor forwards alert information to the Manager, and if configured, the
Manager forwards this information to the syslog server.
However, consider an organization that has more than one Sensor associated with a single Manager.
Let's assume that each Sensor represents a business unit. Security analysts for each business unit
might ask to receive alert information associated only with their business unit. To accommodate such
environments, provision is made to configure those Sensors to forward notifications to a specific
syslog server.
Summarizing the steps that needs to be followed to forward alert notifications to a syslog server:
324
•
Configure a syslog server to make sure it is accessible to the Sensor or the Manager.
•
Either configure the Sensor to directly send notifications to the syslog server or configure the
Manager to send such notifications after consolidating alert information from all devices where
syslog notification is enabled.
•
Enable syslog fowarding in the Manager – at the Manager level, global level, or device level.
•
Determine whether you want to receive all alert notifications or only some depending on the
attacks or the attack severity.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
•
If you have chosen to receive syslog notifications based on the attack definition, configure those
attacks.
•
If you have chosen to receive alert notification based on both attack severity and definition, the
Sensor will give preference to the severity of the attack when deciding whether to forward the
notification or not.
This illustration represents a sample syslog forwarding scenario.
Figure 12-36 Sample syslog forwarding scenario
Alert notifications from the Sensor
You can configure the Sensor to forward alert notifications either at the domain level or the Sensor
level. The next two sections tell you how you can configure the Sensor at different levels.
Enable syslog forwarding for alert notifications at the domain level
Before you begin
Make sure you have configured a syslog server with an IP address that will be reachable to
the respective Sensors.
By configuring settings in the page, you can enable syslog forwarding for all devices in the domain.
Task
1
Select Devices | Admin Domain Name | Global | Default Device Settings | IPS Devices | IPS Event Logging.
2
Configure the following fields.
McAfee Network Security Platform 8.1
IPS Administration Guide
325
12
Working with IPS policies
Alert notification options
Field
Description
Enable Logging
Selecting Enabled displays options to configure settings.
Syslog Server IP
Address
The IP address of the syslog server which becomes the destination of the alert
notifications sent by all devices.
Syslog Server Port
(UDP)
Port on the target syslog server that is authorized to receive syslog messages.
Syslog Facility
Standard syslog prioritization value. The choices are as follows:
The default protocol for syslog forwarding from Sensors is UDP. Therefore, this
port must not be altered.
• Security/authorization (code 4)
• Local user 2 (local2)
• Security/authorization (code 10)
• Local user 3 (local3)
• Log audit (note 1)
• Local user 4 (local4)
• Log alert (note 1)
• Local user 5 (local5)
• Clock daemon (note 2)
• Local user 6 (local6)
• Local user 0 (local0)
• Local user 7 (local7)
• Local user 1 (local1)
Attack Severity to
Syslog Priority
Mapping
Send Test Message
You can map each severity (Informational, Low, Medium, or High) to one of
these standard syslog severities:
• Emergency – System is unusable
• Warning – Warning conditions
• Alert – Action must be taken
immediately
• Notice – Normal but significant
condition
• Critical – Critical conditions
• Informational – Informational
messages
• Error – Error conditions
• Debug – Debug-level messages
Clicking this option sends a test message from the Manager to the syslog
server.
It is used to check whether the syslog server is reachable.
3
Provide any filtering parameters that you want to provide.
Field
Alert
Logging
Description
Log All Attacks sends notifications about every attack that passes through the Sensor.
Log Some Attacks sends notifications about specific attacks based either on the severity or
the settings in the attack definition.
• Selecting The attack definition has syslog notification explicitly enabled instructs the Sensor to
check the attack definition before sending out syslog notifications.
If you only select this checkbox and do not configure any of the attack definitions for
syslog notification, no notifications will be forwarded to the server.
• Selecting Minimum Severity instructs the Sensor to check the severity of the attack before
forwarding the notification. Only attacks of a specific severity and higher will be
forwarded; therefore, you must specify the lowest severity attacks.
For example, if you only select this checkbox and specify Low, all attacks that have a
severity of low or higher will be notified to the server.
4
326
Select the message you want displayed in the notification.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
Field
12
Description
Message The default message is a quick summary of an alert with two fields for easy recognition:
Attack Name and Attack Severity. A default message reads:
Attack $IV_ATTACK_NAME$ ($IV_ATTACK_SEVERITY$).
The variables listed in the table are supported by the Sensor.
Table 12-5
columns
Syslog variables for alert notification and the equivalent Threat Analyzer
Syslog variable name
Description
Threat
Analyzer
column
$IV_ADMIN_DOMAIN$
The domain to which the Sensor that
detected the attack belongs.
Admin Domain
$IV_ALERT_TYPE$
The Sensor decides the type of alert. This is Not available.
mainly used by the Manager for its internal
processing. This is not related to the Attack
Category or Attack Sub-category. Some
example alert types are signature, statistical
anomaly, threshold anomaly, port scan, and
host sweep.
$IV_APPLICATION_PROTOCOL$
The application-layer protocol associated
with the attack traffic. This is not related to
the Application Identification feature, and
this information is displayed even if you
have not enabled Application Identification.
There could be instances when a Sensor
might not be able to detect the protocol.
App Protocol
$IV_ATTACK_CONFIDENCE$
This is a value between 1 and 7. For
example, a confidence level of 7 indicates
that there is low possibility of the attack
being a false-positive.
Not available.
The attack confidence values are inversely
related to the Benign Trigger Probability
(BTP) values of attack signatures.
• Confidence 1 =
BTP 7 (high)
• Confidence 5 =
BTP 3
(medium)
• Confidence 2 =
BTP 6 (high)
• Confidence 6 =
BTP 2 (low)
• Confidence 3 =
BTP 5
(medium)
• Confidence 7 =
BTP 1 (low)
• Confidence 4 =
BTP 4
(medium)
$IV_ATTACK_COUNT$
McAfee Network Security Platform 8.1
The number of types the attack occurred.
This information is more relevant for
suppressed alerts. Consider you have
enabled alert suppression such that the alert
is raised only when the attack is seen 5
times within 30 seconds. Subsequently, the
Sensor detected this attack 10 times within
30 seconds. Then the attack count for this
alert is 10.
Attack Count
(available in the
Alert Details
page).
IPS Administration Guide
327
12
Working with IPS policies
Alert notification options
Table 12-5 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_ATTACK_ID$
McAfee Labs assigns a universally unique
hexadecimal value to each attack. This field
displays the integer value of the
hexadecimal ID assigned by McAfee Labs.
The equivalent
hexadecimal
value is
displayed in the
Attack Information &
Description page
as Intruvert ID.
$IV_ATTACK_NAME$
The name assigned by McAfee Labs to an
attack.
Attack Name
$IV_ATTACK_SEVERITY$
Indicates the severity value of an attack
specified in the corresponding attack
definition.
Severity (high,
medium, low, or
informational)
• 0 - Informational
• 1 to 3 - low
• 4 to 6 - medium
• 7 to 9 - high
328
$IV_ATTACK_SIGNATURE$
The ID of the signature that matched the
attack traffic.
Not available in
the Threat
Analyzer.
$IV_ATTACK_TIME$
The time when the Sensor created the alert.
Time.
$IV_CATEGORY$
The category to which the attack belongs.
This is decided by McAfee Labs. Some
examples are exploit, policy violation, and
reconnaissance. You can view the attack
categories in the IPS Policy Editor when you
group by Attack Category.
Attack Category
$IV_DESTINATION_IP$
The destination IP address to which the
attack is destined.
Dest IP
$IV_DESTINATION_PORT$
The port number on the destination host to
which the attack traffic is sent.
Dest Port
$IV_DEST_APN$
This is the destination Access Point Name
Dest APN
(APN). This information is part of a mobile
subscriber's identity data and is relevant
only if you have deployed Sensors to
monitor mobile networks. To see this data,
you must enable capturing and tagging of
mobile subscriber data in the alerts by using
the set mnsconfig Sensor CLI command.
$IV_DEST_IMSI$
This is the destination International Mobile
Subscriber Identity (IMSI). The details
provided for APN apply to this as well.
Dest IMSI
$IV_DEST_OS$
The operating system installed on the
destination host. In release 7.5.3, to see
this information, you must have enabled
Active or Passive Device Profiling.
Dest OS
$IV_DEST_PHONE_NUMBER$
This is the destination mobile phone number. Dest Phone
The details provided for APN above apply to
this as well.
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Table 12-5 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_DETECTION_MECHANISM$
The method the Sensor used to detect the
attack. For example, signature,
multi-flow-correlation, threshold, and so on.
Each method relates to a specific attack
category.
Detection
Mechanism
$IV_DIRECTION$
Indicates whether the attack traffic
Direction
originated from your network or the outside
network. For example, inbound direction
means that the attack traffic originated from
the outside network, targeting the hosts on
your network.
$IV_INTERFACE$
The interface or sub-interface on which the
Sensor detected the attack traffic.
Interface
$MALWARE_CONFIDENCE$
Confidence level of the malware as detected
by the engine
Not available
$MALWARE_DETECTION_ENGINE$ Engine which detected the
malware(GAM,GTI,PDF‑JS,etc).
Not available
$MALWARE_FILE_LENGTH$
The length of the malware file.
Not available
$MALWARE_FILE_MD5_HASH$
The MD5 hash of the malware
file(fingerprint).
Not available
$ MALWARE_FILE_NAME$
The name of the malware file. For SMTP
traffic, it displays the file name of the
attachment and for HTTP traffic, it displays
the URL of the file.
Not available
$ MALWARE_FILE_TYPE$
The file type of the malware file
Not available
$MALWARE_VIRUS_NAME$
The virus name as detected by GAM.
Not available
$IV_NETWORK_PROTOCOL$
The network protocol, such as TCP, of the
attack traffic.
Network
Protocol
available in the
Alert Details
page.
$IV_QUARANTINE_END_TIME$
The time when the attacking host will be out Not available.
of quarantine. This is relevant only if you
had enabled Quarantine feature.
In the Threat Analyzer, you can view the
quarantine end time under the Quarantined
Until column in the Hosts tab.
$IV_RESULT_STATUS$
Indicates whether the attack traffic reached
the victim host.
Result
$IV_SENSOR_ALERT_UUID$
The universally unique ID assigned by the
Sensor for the alert. For a specific alert
raised by a specific Sensor, the Central
Manager also displays the same ID.
Alert ID
$IV_SENSOR_CLUSTER_MEMBER$ The member Sensor of a failover pair that
generated the alert.
Not available.
$IV_SOURCE_IP$
The IP address of the attacking host.
Src IP
$IV_SOURCE_PORT$
The port number on the attacking host from
which the attack traffic is sent.
Src Port
McAfee Network Security Platform 8.1
IPS Administration Guide
329
12
Working with IPS policies
Alert notification options
Table 12-5 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
5
Syslog variable name
Description
Threat
Analyzer
column
$IV_SRC_APN$
This is the source Access Point Name (APN). Src APN
This information is part of a mobile
subscriber's identity data and is relevant
only if you have deployed Sensors to
monitor mobile networks. To see this data,
you must enable capturing and tagging of
mobile subscriber data in the alerts by using
the set mnsconfig Sensor CLI command.
$IV_SRC_IMSI$
This is the source International Mobile
Subscriber Identity (IMSI). The details
provided for APN apply to this as well.
$IV_SRC_PHONE_NUMBER$
This is the source mobile phone number. The Src Phone
details provided for APN apply to this as
well.
$IV_SUB_CATEGORY$
The subcategory to which the attack
belongs. This is decided by McAfee Labs,
and is a classification within Attack
Category. Some examples are brute-force,
buffer-overflow, host-sweep, and
restricted-application. You can view the
attack subcategories in the IPS Policy Editor
when you group by Attack Subcategory.
Attack
Subcategory
$IV_VLAN_ID$
The VLAN ID seen on the attack traffic.
VLAN
Src IMSI
Click Save.
You have now enabled syslog forwarding for all Sensors belonging to a domain. You will notice in the
IPS Event Logging page of a Sensor that all settings you have just configured are automatically inherited
by each Sensor. The only remaining step to begin sending notifications will be to perform a
configuration update in each Sensor.
Figure 12-37 IPS Event Logging at the Sensor level inherits domain settings automatically
However, if you want to modify settings for any of the Sensors, you will need to configure these
settings individually for each Sensor. To configure a Sensor for syslog forwarding, go to Enable syslog
forwarding for alert notifications at the Sensor level on page 331
330
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Enable syslog forwarding for alert notifications at the Sensor level
Before you begin
Make sure you have configured a syslog server with an IP address that will be reachable to
the respective Sensors.
By configuring settings in this page, you will be able to enable syslog forwarding for the Sensor. Unless
you inherit settings from the domain, any configuration in this page will over-ride settings defined at
the domain level.
Task
1
Select Devices | Admin Domain Name | Devices | <Device Name> | Setup | Logging | IPS Event Logging.
2
If you want to use settings configured for the domain, select the Inherit Settings checkbox.
3
Click Save to complete the configuration. However, if you want to configure settings at the Sensor
level, see Enable syslog forwarding for alert notifications at the domain level on page 325 .
After you complete configuring these settings, syslog forwarding for the Sensor is enabled.
Forward alert notifications from the Manager to a syslog server
Syslog forwarding enables you to view the forwarded alerts from third-party syslog applications that
support UDP and TCP over SSL, for example, Syslog NG.
Task
1
Select Manage | <Admin Domain Name> | Setup | Notification | IPS Events | Syslog.
Figure 12-38 Syslog page
2
Click Yes in Enable Syslog Notification to enable syslog forwarding of alerts.
3
Click Save.
You can forward Sensor alerts to multiple syslog servers by creating new syslog notification profiles.
You can forward IPS alerts to syslog servers using UDP or TCP (with or without SSL).
Tasks
•
Add a syslog notification profile on page 331
•
Edit or delete a syslog notification profile on page 338
•
Add a syslog server profile on page 338
•
Edit or delete a syslog server profile on page 339
Add a syslog notification profile
You can add notification profiles that will be displayed on the Syslog page.
McAfee Network Security Platform 8.1
IPS Administration Guide
331
12
Working with IPS policies
Alert notification options
Task
1
Click New on the Syslog page.
The Add a Syslog Notification Profile page is displayed.
2
Specify your options in the corresponding fields.
Figure 12-39
Syslog Notification Profile page
Field
Description
Admin Domain
• Current— Send notifications for alerts in the current domain. Always enabled for
current domain by default.
• Children— Include alerts for all child domains of the current domain. (Not applicable
to NTBA.)
Notification
Profile Name
Profile name from where notifications are sent.
Target Server
TCP (with or without SSI) or UDP— Port on the target syslog server that is authorized
to receive syslog messages.
See also Adding a syslog server profile.
Facility
Standard syslog prioritization value. The choices are as follows:
• Security/authorization (code 4)
• Local user 2 (local2)
• Security /authorization (code 10)
• Local user 3 (local3)
• Log audit (note 1)
• Local user 4 (local4)
• Log alert (note 1)
• Local user 5 (local5)
• Clock daemon (note 2)
• Local user 6 (local6)
• Local user 0 (local0)
• Local user 7 (local7)
• Local user 1 (local1)
332
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
Field
Description
Severity
Mappings
You can map each severity (Informational, Low, Medium, or High) to one of the
standard syslog severities listed below:
Notify for All
Alerts
• Emergency— System is unusable
• Warning— Warning conditions
• Alert— Action must be taken
immediately
• Notice— Normal but significant
condition
• Critical— Critical conditions
• Informational— Informational
messages
• Error— Error conditions
• Debug— Debug-level messages
12
By default, this checkbox will be selected. Notifies for all discovered attacks.
The following field is enabled only on deselecting the Notify for All Alerts checkbox.
Only Notify
When
The attack definition has this notification option explicitly enabled:
Send notification for attacks that match customized policy notification settings,
which you must set when editing attack responses within the policy editor (<Admin
Domain Node> | IPS settings | Policies | IPS Policies) based on the following filters:
• Severity High— Includes only high severity alerts.
• Severity Informational and above— Includes all alerts.
• Severity Low and above— Includes low, medium, and high severity alerts.
• Severity Medium and above— Includes both medium and high severity alerts.
Notify on
Quarantine
Events (not
applicable
to NTBA
Appliance)
Select this checkbox to see quarantine events.
Message
The default message is a quick summary of an alert with two fields for easy
recognition: Attack Name and Attack Severity. A default message reads:
$IV_SENSOR_NAME$ detected $IV_DIRECTION$ attack $IV_ATTACK_NAME$
(severity = $IV_ATTACK_SEVERITY$). $IV_SOURCE_IP$:$IV_SOURCE_PORT$ ->
$IV_DESTINATION_IP$:$IV_DESTINATION_PORT$ (result = $IV_RESULT_STATUS$)
For syslog message to appear correctly, ensure that you use the dollar-sign ($)
delimiter immediately before and after each parameter. Example: $ATTACK_TIME$
Type a message and select (click) the parameters for the wanted alert identification
format. You can type custom text in the Message field.
3
Click Save.
The newly added notification profile will be displayed on the Syslog page.
McAfee Network Security Platform 8.1
IPS Administration Guide
333
12
Working with IPS policies
Alert notification options
Table 12-6
columns
Syslog variables for alert notification and the equivalent Threat Analyzer
Syslog variable name
Description
Threat
Analyzer
column
$IV_ADMIN_DOMAIN$
The domain to which the Sensor that
detected the attack belongs.
Admin Domain
$IV_ALERT_ID$
The globally unique ID that the Manager
assigns to an alert. .
Not available.
$IV_ALERT_TYPE$
The Sensor decides the type of alert. This is Not available.
mainly used by the Manager for its internal
processing. This is not related to the Attack
Category or Attack Sub-category. Some
example alert types are signature, statistical
anomaly, threshold anomaly, port scan, and
host sweep.
$IV_APPLICATION_PROTOCOL$
The application-layer protocol associated
with the attack traffic. This is not related to
the Application Identification feature, and
this information is displayed even if you
have not enabled Application Identification.
There could be instances when a Sensor
might not be able to detect the protocol.
App Protocol
$IV_ATTACK_CONFIDENCE$
This is a value between 1 and 7. For
example, a confidence level of 7 indicates
that there is low possibility of the attack
being a false-positive.
Not available.
The attack confidence values are inversely
related to the Benign Trigger Probability
(BTP) values of attack signatures.
• Confidence 1 =
BTP 7 (high)
• Confidence 5 =
BTP 3
(medium)
• Confidence 2 =
BTP 6 (high)
• Confidence 6 =
BTP 2 (low)
• Confidence 3 =
BTP 5
(medium)
• Confidence 7 =
BTP 1 (low)
• Confidence 4 =
BTP 4
(medium)
$IV_ATTACK_COUNT$
334
McAfee Network Security Platform 8.1
The number of types the attack occurred.
This information is more relevant for
suppressed alerts. Consider you have
enabled alert suppression such that the alert
is raised only when the attack is seen 5
times within 30 seconds. Subsequently, the
Sensor detected this attack 10 times within
30 seconds. Then the attack count for this
alert is 10.
Attack Count
(available in the
Alert Details
page).
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Table 12-6 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_ATTACK_ID$
McAfee Labs assigns a universally unique
hexadecimal value to each attack. This field
displays the integer value of the
hexadecimal ID assigned by McAfee Labs.
The equivalent
hexadecimal
value is
displayed in the
Attack Information &
Description page
as Intruvert ID.
$IV_ATTACK_NAME$
The name assigned by McAfee Labs to an
attack.
Attack Name
$IV_ATTACK_SEVERITY$
Indicates the severity value of an attack
specified in the corresponding attack
definition.
Severity (high,
medium, low, or
informational)
• 0 - Informational
• 1 to 3 - low
• 4 to 6 - medium
• 7 to 9 - high
$IV_ATTACK_SIGNATURE$
The ID of the signature that matched the
attack traffic.
Not available in
the Threat
Analyzer.
$IV_ATTACK_TIME$
The time when the Sensor created the alert. Time.
$IV_CATEGORY$
The category to which the attack belongs.
This is decided by McAfee Labs. Some
examples are exploit, policy violation, and
reconnaissance. You can view the attack
categories in the IPS Policy Editor when you
group by Attack Category.
Attack Category
$IV_DESTINATION_CRITICALITY$ The criticality of the destination host
Dest criticality
$IV_DESTINATION_IP$
The destination IP address to which the
attack is destined.
Dest IP
$IV_DESTINATION_NAME$
The name of the destination host.
Dest Name
$IV_DESTINATION_PORT$
The port number on the destination host to
which the attack traffic is sent.
Dest Port
$IV_DEST_APN$
This is the destination Access Point Name
Dest APN
(APN). This information is part of a mobile
subscriber's identity data and is relevant
only if you have deployed Sensors to
monitor mobile networks. To see this data,
you must enable capturing and tagging of
mobile subscriber data in the alerts by using
the set mnsconfig Sensor CLI command.
$IV_DEST_IMSI$
This is the destination International Mobile
Subscriber Identity (IMSI). The details
provided for APN apply to this as well.
Dest IMSI
$IV_DEST_OS$
The operating system installed on the
destination host. In release 7.5.3, to see
this information, you must have enabled
Active or Passive Device Profiling.
Dest OS
McAfee Network Security Platform 8.1
IPS Administration Guide
335
12
Working with IPS policies
Alert notification options
Table 12-6 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_DEST_PHONE_NUMBER$
This is the destination mobile phone
number. The details provided for APN above
apply to this as well.
Dest Phone
$IV_DETECTION_MECHANISM$
The method the Sensor used to detect the
Detection
attack. For example, signature,
Mechanism
multi-flow-correlation, threshold, and so on.
Each method relates to a specific attack
category.
$IV_DIRECTION$
Indicates whether the attack traffic
Direction
originated from your network or the outside
network. For example, inbound direction
means that the attack traffic originated from
the outside network, targeting the hosts on
your network.
$IV_INTERFACE$
The interface or sub-interface on which the
Sensor detected the attack traffic.
$LAYER_7_DATA$
The Application Layer Data (HTTP, SMTP, FTP Layer & Data
etc) sent from the Sensor.
$MALWARE_CONFIDENCE$
Confidence level of the malware as detected Not available
by the engine
Interface
$MALWARE_DETECTION_ENGINE$ Engine which detected the
malware(GAM,GTI,PDF‑JS,etc).
Not available
$MALWARE_FILE_LENGTH$
The length of the malware file.
Not available
$MALWARE_FILE_MD5_HASH$
The MD5 hash of the malware
file(fingerprint).
Not available
$ MALWARE_FILE_NAME$
The name of the malware file. For SMTP
traffic, it displays the file name of the
attachment and for HTTP traffic, it displays
the URL of the file.
Not available
$ MALWARE_FILE_TYPE$
The file type of the malware file
Not available
$MALWARE_VIRUS_NAME$
The virus name as detected by GAM.
Not available
$IV_NETWORK_PROTOCOL$
The network protocol, such as TCP, of the
attack traffic.
Network
Protocol
available in the
Alert Details
page.
$IV_QUARANTINE_END_TIME$
The time when the attacking host will be out Not available.
of quarantine. This is relevant only if you
had enabled Quarantine feature.
In the Threat Analyzer, you can view the
quarantine end time under the Quarantined
Until column in the Hosts tab.
336
$IV_RELEVANCE$
An indication whether the target is really
vulnerable for the attack. This is based on
the information from McAfee Vulnerability
Manager.
Relevance
$IV_RESULT_STATUS$
Indicates whether the attack traffic reached
the victim host.
Result
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Table 12-6 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_SENSOR_ALERT_UUID$
The universally unique ID assigned by the
Sensor for the alert. For a specific alert
raised by a specific Sensor, the Central
Manager also displays the same ID.
Alert ID
$IV_SENSOR_CLUSTER_MEMBER$ The member Sensor of a failover pair that
generated the alert.
Not available.
$IV_SENSOR_NAME$
The Sensor that generated the alert..
Device
$SOURCE_CRITICALITY$
The criticality of the attacking host
Src criticality
$IV_SOURCE_IP$
The IP address of the attacking host.
Src IP
$IV_SOURCE_PORT$
The port number on the attacking host from Src Port
which the attack traffic is sent.
$IV_SOURCE_VM_ESX_NAME$
This is the VMware ESX server from which
the attack traffic originated. This
information is relevant only if deployed a
Sensor monitoring port to inspect VMware
traffic. For this you need to deploy a
monitoring port as a VM-Aware port.
Not available.
$IV_SOURCE_VM_NAME$
This is the name of the VMware host from
which the attack traffic originated.
Src VM Name
$IV_SRC_APN$
This is the source Access Point Name (APN). Src APN
This information is part of a mobile
subscriber's identity data and is relevant
only if you have deployed Sensors to
monitor mobile networks. To see this data,
you must enable capturing and tagging of
mobile subscriber data in the alerts by using
the set mnsconfig Sensor CLI command.
$IV_SRC_IMSI$
This is the source International Mobile
Subscriber Identity (IMSI). The details
provided for APN apply to this as well.
$IV_SRC_PHONE_NUMBER$
Src Phone
This is the source mobile phone number.
The details provided for APN apply to this as
well.
$IV_SUB_CATEGORY$
The subcategory to which the attack
belongs. This is decided by McAfee Labs,
and is a classification within Attack
Category. Some examples are brute-force,
buffer-overflow, host-sweep, and
restricted-application. You can view the
attack subcategories in the IPS Policy Editor
when you group by Attack Subcategory.
Attack
Subcategory
$IV_TARGET_VM_ESX_NAME$
This is the target VMware ESX server. This
information is relevant only if deployed a
Sensor monitoring port to inspect VMware
traffic. For this you need to deploy a
monitoring port as a VM-Aware port.
Not available.
$IV_TARGET_VM_NAME$
This is the name of the target VMware host.
Dest VM Name
McAfee Network Security Platform 8.1
Src IMSI
IPS Administration Guide
337
12
Working with IPS policies
Alert notification options
Table 12-6 Syslog variables for alert notification and the equivalent Threat Analyzer
columns (continued)
Syslog variable name
Description
Threat
Analyzer
column
$IV_URI_INFO$
The URI found in the attack traffic.
In Network
Security
Platform 6.1, it
is URL. From
Network
Security
Platform 7.0, it
is Layer 7 Data.
$IV_VLAN_ID$
The VLAN ID seen on the attack traffic.
VLAN
Edit or delete a syslog notification profile
You can edit or delete a syslog notification profile by clicking the Edit or Delete in the Syslog Notification
Profile page.
Add a syslog server profile
You can add server profiles that will be populated in the Target Server drop-down list on the Add a Syslog
Notification Profile page.
Task
1
Click New beside the Target Server drop-down list.
The Add a Syslog Server Profile page is displayed.
Figure 12-40 Add a Syslog Server Profile window
2
Enter the target server profile name.
3
Enter the syslog server name or IP address.
4
Select TCP or UDP from the Protocol drop-down list.
If you select the TCP protocol:
•
You will have to provide a certificate when you select the Use SSL checkbox.
•
Click Test Connection to check if the connection is successful. If a TCP server is down, at
least five attempts will be made to ping the server before a fault is raised.
5
Specify the port. By default, the port is set to 0; this is an invalid port.
6
Click Save.
Now you can select the server where you want to forward the alert.
338
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Edit or delete a syslog server profile
You can edit or delete a syslog server profile by clicking the Edit or Delete in the Syslog Notification Profile
page.
You can delete a syslog server only when it is not in use, else you will see an error message.
Configure email or pager alert notifications
Before you begin
You must identify a mail server for email notifications in the E-mail Server page (Manage | Setup
| E-mail Server).
Users can be alerted by email or pager when an alert is generated that matches a chosen severity or
customized attack setting.
The procedure for configuring email alerts is described here. The procedure for configuring pager is
similar.
Task
1
Select Manage | Setup | Notification | IPS/NTBA Events | E-mail.
The E-Mail and Recipient List information is displayed under the E-mail tab.
Figure 12-41 E-mail page
2
Specify your options in the corresponding fields.
McAfee Network Security Platform 8.1
IPS Administration Guide
339
12
Working with IPS policies
Alert notification options
Field
Description
Enable E-mail
Notification
Select Yes to enable alert notification through email.
Send Notification
If
The attack definition has this notification option explicitly enabled — Send notification for attacks
that match customized policy notification settings, which you must set when
editing attack responses within the policy editor.
The following notification filter is matched — Send notification based on the following
filters:
• Allow All — Notifies for all discovered attacks.
• Block All — Blocks notification.
• Severity Informational and above — Includes all alerts.
• Severity Low and above — Includes low, medium, and high severity alerts.
• Severity Medium and above — Includes both medium and high severity alerts
• Severity High — Includes only high severity alerts.
Suppression Time Type a Suppression Time for the notification. The suppression time is the duration
(minutes and seconds) to wait after an alert notification has been sent before
sending another alert notification. The default and minimum value is 10 minutes
and 0 seconds. Suppression time is useful to avoid sending excessive notifications
when there is heavy attack traffic.
3
Select a Message Body (System default or Customized).
The message body is a preset response sent with the notification with information pertaining to the
alert.
•
System Default — The system default message provides the notified admin with the most basic
attack details so that an immediate response can be made. Details include the attack name,
time detected, attack type, severity, the Sensor interface where detected, and the source
and/or destination IP addresses.
You cannot edit the System Default message.
•
Customized — Select Customized against Message Body and click Edit to view the Custom Message page.
You can type custom text in the Subject field or Body section, as well as click one or more of the
provided variable links at Subject Line Variables or Content-Specific Variables.
Click Save to return to the email or pager notification settings page.
4
Click New in the Recipient List section of the E-mail page.
The Add a Recipient page is displayed.
5
Enter the Recipient email address in the SMTP Address field and click Save.
The email address is listed under the Recipient List in the E-mail tab.
•
You can configure pager sittings using a similar procedure in the Pager page. Select Manage | Setup
| Notification | Alerts | IPS | Pager to view the Pager page.
•
Email and pager notifications are configured per admin domain.
Enable alert notification by script
Users can be alerted through an executed script when an alert is generated that matches a chosen
severity or customized attack setting.
340
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with IPS policies
Alert notification options
12
Task
1
Select Manage | Setup | Notification | IPS/NTBA Events | Script.
The Script page is displayed.
2
Specify the options in the corresponding fields.
Figure 12-42 Script page
Table 12-7 Script configuration options
Field
Description
Enable Script
Execution
Select Yes to enable alert notification through an executed script.
Send Notification If
The attack definition has this notification option explicitly enabled — send notification for
attacks that match customized policy notification settings, which you must set
when editing attack responses within the policy editor.
The following notification filter is matched:
• Allow All — Notifies for all discovered attacks
• Block All — Blocks notification
• Severity Informational and above — Includes all alerts
• Severity Low and above — Includes low, medium, and high severity alerts
• Severity Medium and above — Includes both medium and high severity alerts
• Severity High — Includes only high severity alerts
Suppression Time
3
Enter a Suppression Time for the notification. The suppression time is the amount of
time (minutes and seconds) to wait after an alert has been generated before
sending the notification. This will prevent alerts being sent through notification
in the event an alert has been acknowledged or deleted through the Threat
Analyzer within the suppression time. The default and minimum value is 10
minutes and 0 seconds.
Click Edit.
McAfee Network Security Platform 8.1
IPS Administration Guide
341
12
Working with IPS policies
Alert notification options
The Script Contents page is displayed.
Figure 12-43 Script Contents page
342
•
Enter a description in the Description field.
•
Enter the required text in the Script Content field. Click the links provided against Content-Specific
Variables to add variables in the Script Content field.
4
Click Save to return to the Script page.
5
Click Save to save your settings.
•
The local system user needs to have permission to create the script output file on the Manager
installation directory.
•
Notifications are configured per admin domain.
McAfee Network Security Platform 8.1
IPS Administration Guide
13
Device Profiling and Alert Relevance
Contents
Device Profiling
Alert relevance
Device Profiling
Device profiling (also referred to as OS fingerprinting) is a method by which Network Security Platform
collects information about a remote computing device to decipher its operating system and device
type. Network Security Platform carries out device profiling by using DHCP DISCOVER and REQUESTS,
HTTP User Agent field, and TCP SYN and SYN + ACK packets.
If device profiling is enabled, the following McAfee products, when integrated, participate in device
profiling:
•
IPS
•
NTBA
•
McAfee ePO
Device profiling can be carried out in three ways:
•
Active device profiling
•
Passive device profiling
•
Device profiling using McAfee ePO
Active device profiling involves querying a device and observing its responses. Active device
profiling systems gain access to information such as MAC addresses, operating system, and device
type. In Network Security Platform, this method of profiling is used by NTBA. For information about
device profiling using NTBA, refer the Network Security Platform 7.5 Network Threat Behavior Analysis
Administration Guide.
Passive device profiling involves collecting information without invasive querying a device.
Information is collected from one or more Sensors. It uses DHCP DISCOVER and REQUESTS, HTTP
User Agent field, and TCP SYN and SYN + ACK to gather operating system information about a device.
The operating system information about a specific device is displayed in the Real-Time Threat
Analyzer. In Network Security Platform, this method of profiling is used by IPS Sensors.
Device profiling using McAfee ePO functions by making use of communication established McAfee
Agent and McAfee ePO. When McAfee Agent is installed on any system, that system comes to be
known as a managed host and passes device, operating system and other event details at regular
intervals to McAfee ePO. When McAfee ePO is integrated with the Manager, it passes on information
necessary for device profiling.
McAfee Network Security Platform 8.1
IPS Administration Guide
343
13
Device Profiling and Alert Relevance
Device Profiling
Passive Device Profiling
Passive device profiling is a method used specifically by IPS Sensors which are one of the primary
sources of device profile information. Device profiling through IPS is passive. When traffic passes
through a Sensor, its packets are examined and device information extracted by the Sensor, which
then forwards the information to the Manager.
Setting device profiling parameters for all Sensors belonging to a domain
Task
1
Go to Devices | <Admin Domain Name> | Global | Default Device Settings | IPS Devices | Passive Device Profiling.
The Passive Device Profiling page appears.
2
Select the technique that you would like the Manager to use for device profiling.
You will notice three checkboxes:
•
DHCP indicates the use of DHCP DISCOVER and REQUESTS packets for device profiling.
•
TCP indicates the use of TCP SYN and SYN + ACK packets for device profiling.
•
HTTP indicates the use of HTTP User Agent field for device profiling.
The above mentioned techniques are enabled, by default, at the global level. However, to ensure
that device profiling is enabled, you must configure the settings per device or per interface using the
Protection Profile page.
3
Specify the Profile Expiration duration.
This timer ensures periodic re-profiling of a device happens only once within that interval. McAfee
recommends this duration be set at 5 minutes. However, you can alter this and increase it up to 12
hours.
4
Specify the Host Inactivity Timer duration.
This value specifies the duration after which information for a device is considered invalid. It occurs
when the host has remained idle for the said duration. This timer ensures that the sensor will
renew its detection of the IP if it is noticed again. McAfee recommends this duration be set at 1
hour. However, you can alter this and increase it up to 24 hours.
The parameters set in steps 2, 3, and 4 can be over-ridden or inherited at the device or interface
level using the Protection Profile page.
5
Click Save.
Configure device profiling per device or per interface
To access device profiling settings in the Manager, perform the following steps:
Task
1
The Manager allows you to define settings for the device or interface from two paths.
•
To modify device profile settings at the device level, go to Devices | <Admin_Domain_Name> | Devices |
<Device_Name> | Policy | Protection Profile.
•
To modify device profile settings at the interface level, go to Devices | <Admin_Domain_Name> |
Devices | IPS Interfaces | <interface-x name> | Protection Profile.
Irrespective of which path you choose, you will be routed to the same page and will be presented
with the same options.
344
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Device Profiling
13
The Protection Profile page appears.
2
In the Protection Options section, click Passive Device Profiling.
The Passive Device Profiling page appears.
Figure 13-1 Passive Device Profiling page
3
Select the State.
If you select Profiling enabled for the entire device or Enable profiling per interface, proceed with the
configuration. If you select Disabled(entire device), click Save to complete the configuration.
4
You must now decide whether you want to inherit settings from the IPS admin domain by selecting
the Inherit Settings checkbox.
Selecting this checkbox means either the entire device or this specific interface will inherit global
settings and no further options will appear in this page. If you have not chosen to inherit settings
from the admin domain, proceed to Step 5.
5
Select the techniques that you want to use for device profiling.
You will find three checkboxes:
6
•
DHCP indicates the use of DHCP DISCOVER and REQUESTS packets for device profiling.
•
TCP indicates the use of TCP SYN and SYN + ACK packets for device profiling.
•
HTTP indicates the use of HTTP User Agent field for device profiling.
Specify the Profile Expiration duration.
This timer ensures periodic re-profiling of a device to detect any changes in that period. McAfee
recommends this duration be set at 5 minutes. However, you can increase it up to 12 hours.
McAfee Network Security Platform 8.1
IPS Administration Guide
345
13
Device Profiling and Alert Relevance
Device Profiling
7
Specify the Host Inactivity Timer duration.
This value specifies the duration after which information for a device is considered invalid. It occurs
when the host has remained idle for the said duration. This timer ensures that the sensor will
renew its detection of the IP address if it is noticed again. McAfee recommends this duration be set
at 1 hour. However, you can increase it up to 24 hours.
8
If you selected DHCP as your preference, you will need make sure that DHCP traffic actually passes
through the Sensor monitoring port. If not, you have the provision to configure the monitoring port
of a Sensor with an IP address to receive DHCP traffic through a relay agent. Provide these settings
by selecting Bind an IP Address For Copied DHCP Traffic?.
If you are using an XC Cluster, you will not be able to bind the monitoring port with an IP address
and will not be able to set up a DHCP relay agent.
Using the DHCP Relay Agent
A DHCP relay agent is any host that facilitates transfer of DHCP packets between clients and
servers. Relay agents are used to forward requests and replies between clients and servers when
they are not on the same physical subnet.In the illustration provided Sensor A exists in a specific
physical subnet and the clients for which the Sensor needs to monitor DHCP traffic exist in another
physical subnet. In such a network, you can use a DHCP Relay Agent to make sure that DHCP
traffic from the clients in the other subnet reaches Sensor A. To accomplish this, you will need use
a device such as a router (we will consider a CISCO router that runs CISCO IOS software). The
DHCP client broadcasts a request for an IP address and additional configuration parameters on its
local LAN. Router 1, which plays the role of a DHCP relay agent, picks up the broadcast and
generates a new DHCP message to send out on another interface. As part of this DHCP message,
the relay agent inserts the IP address of the interface containing the ip helper‑address command into
the gateway IP address (giaddr) field of the DHCP packet, which will be the Sensor monitoring port
IP address, 10.32.221.2. The DHCP relay agent sends the local broadcast, via IP unicast, to the
Sensor monitoring port address, 10.32.221.2, specified by the ip helper‑address interface
configuration command. This enables Sensor A to monitor DHCP traffic in another physical subnet.
Figure 13-2 DHCP Relay Agent
a
Select the Designated Port which will function as the monitoring port.
b
Enter the Port IP Address, Network Mask, Default Gateway, and VLAN ID of the Sensor monitoring port.
This is the same IP address that you will provide in the relay agent configuration settings.
9
346
Click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Device Profiling
13
Limitations of passive device profiling
Passive device profiling in IPS consists certain limitations which are enforced by other settings or
hardware. These limitations are as follows:
•
Profiling for devices with IPv6 addresses is currently supported only for HTTP device profiling.
•
Device profiling will not happen for a host which:
•
•
Has the SYN cookie feature activated.
•
Has encountered an IGNORE firewall rule.
Sensors have a limit on the number of profiles that they can process. This limit depends on the
Sensor model. The Sensor models along with their specific limits are listed in the table below.
Table 13-1 Profile Limits
Sensor Model
Profile Limits (No. of profiles)
M-6050, M-8000
100,000
M-4050
50,000
M-3050
25,000
M-2750, M-2850, M-2950
15,000
M-1450
10,000
M-1250
5000
Device Profiling using McAfee ePolicy Orchestrator
McAfee ePolicy Orchestrator software is a management platform that enables centralized policy
management and enforcement of your security products and the systems on which they reside.
However, for ePolicy Orchestrator to function, McAfee Agent needs to be installed on the client
systems. The agent facilitates enforcement between theePolicy Orchestrator server and each managed
client system. It retrieves updates, ensures task implementation, enforces policies, and forwards
events for each managed system. As a ePolicy Orchestrator becomes a repository of information and
can be used in device profiling.
This information can also be viewed directly in ePolicy Orchestrator, even if it does not participate in
device profiling.
The Manager sends a query to ePolicy Orchestrator when seeking information about a device profile. It
accepts device information from ePolicy Orchestrator and in case of Windows platforms, always trusts
information received from ePolicy Orchestrator over others.
Requirements for device profiling using ePolicy Orchestrator
The list of requirements to consider before you begin using ePolicy Orchestrator for device profiling is
as follows:
•
Server that hosts ePolicy Orchestrator 4.6 Patch 3 or above.
•
McAfee Agent 4.6 Patch 2 or above installed on the clients, for which device profiling is necessary.
•
Integration of ePolicy Orchestrator with the Manager.
Set up the ePolicy Orchestrator server
To find out how you can setup an ePolicy Orchestrator server, please refer the McAfee® ePolicy
Orchestrator® 4.6.0 Software Installation Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
347
13
Device Profiling and Alert Relevance
Device Profiling
Set up McAfee Agent on managed clients
To find out how you can setup McAfee Agent on managed client systems, refer the McAfee® Agent
4.6.0 Product Guide.
Integrate ePolicy Orchestrator and the Manager
Task
1
Go to Manage | <Admin Domain Name> | Integration | ePolicy Orchestrator | ePO Integration.
The Enable ePolicy Orchestrator page appears.
2
Select Yes for Enable Detailed Host Query?.
3
Select Yes for Enable Mouse-Over Host Summary?.
Enabling this option allows you to mouse over an IP address in the Threat Analyzer Alerts page to
display a summary of essential host data such as, host name, current user, and operating system
version. The summary is visible in the Alerts page only when the ePolicy Orchestrator integration is
also enabled in the Manager.
4
Click Next.
The ePolicy Orchestrator Server Settings page appears.
Figure 13-3 ePO Server Settings page
5
Click the ePolicy Orchestrator Extension link to download the NSPExtension.zip which is the ePolicy
Orchestrator extension file.
6
Save the file in a convenient location in the local hard disk.
7
Log on to the ePolicy Orchestrator console.
The ePolicy Orchestrator home page appears.
8
Go to Menu | Software | Extensions.
The Extension page appears.
9
348
Click Install Extension at the bottom of the page.
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Device Profiling
13
10 Browse to the location that you have stored NSPExtension.zip.
Once installed, the Manager is listed under the Extensions list.
11 Close ePolicy Orchestrator and return to the Manager.
12 Go to Manage | <Admin Domain Name> | Integration | ePolicy Orchestrator | ePO Integration.
Field
Description
Server Name /
IP Address
Enter the name or the IP of the McAfee ePO™ server running the extension file.
Note that this McAfee ePO™ server should have the details of the hosts covered
by the admin domain.
Contact your McAfee ePO™ administrator for the server name and IP.
Server Port
Specify the HTTPS listening port on the McAfee ePO™ server that will be used for
the Manager -McAfee ePO™ communication. Contact your McAfee ePO™
administrator for the port number.
User Name
Enter the username to be used while connecting to the McAfee ePO™ server.
McAfee recommends you create an McAfee ePO™ user account with View-only
permissions required for integration.
Password
Enter the password for connecting to the McAfee ePO™ server.
The Enable ePolicy Orchestrator page appears.
13 Specify ePolicy Orchestrator server details as described in the following table.
14 Click Test Connection to ensure that the extension file is installed and started on the ePolicy
Orchestrator server.
15 If the connection is up, then click Save.
Display of device profiles in the Manager
After you have configured the various sources for device profiling, you will be able to view device
profiles in the Manager. There are two methods to view device profiles:
•
Using the Threat Analyzer: In this method, the device profiles are visible in the form of source and
destination operating systems. As stated earlier, the Manager receives device profile information
from three sources, IPS Sensors, NTBA Appliances and ePolicy Orchestrator. Each of these inputs
consists of a confidence level which is compared by the Manager, which then presents the device
profile that has the highest confidence. Knowledge of the operating system allows the Manager to
ascribe a relevance to each alert. Relevance helps prioritize an alert since certain alerts will only be
relevant to certain operating systems; if not applicable to an operating system, such alerts are
treated as not relevant. For more information on relevance, refer the Section, Alert Relevance.
•
Using the device-profile script: In this method, you initiate the device-profile script that is bundled
with the Manager installable. This script fetches the device profiles of all the hosts that the
Manager currently has in its database. The script displays this data in a .csv file.
McAfee Network Security Platform 8.1
IPS Administration Guide
349
13
Device Profiling and Alert Relevance
Device Profiling
In the Threat Analyzer, you can only view the source and destination operating systems of the
hosts associated with an alert. That is, if a host is not associated with an alert, then you cannot
view its operating system even if the Manager has this information. If you use the device-profile
script, you can view the following details for all the hosts that are currently profiled:
•
operating system
•
the device type
•
the source of the profile - IPS Sensor, NTBA Appliance, or ePolicy Orchestrator
View device profiles in the Threat Analyzer
You can view the device profiles in the Real-Time and Historical Threat Analyzers. To view device
profiles in the Real-Time Threat Analyzer of the Manager:
Task
1
Go to Analysis | <Admin Domain Name> | Threat Analyzer | Real-Time.
2
Click Start the Real-Time Threat Analyzer.
You will be prompted to download the Java applet.
3
Download the file and open it.
In a few moments, the Threat Analyzer page appears.
4
In the Threat Analyzer window, click Alerts.
5
By default, the page displays the All Alerts tab.
6
Scroll to find the Src OS and Dest OS columns. If these columns are not present, add them.
7
To add the columns, right click one of the column titles.
8
Go to Show Column and select Src OS.
9
Repeat Step 8 and select Dest OS.
The source and destination operating systems are visible in the Threat Analyzer, indicating the device
profiles and device types of various devices.
Figure 13-4 Display of device profiles in the Manager
350
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Device Profiling
13
View device profiles using the device-profile script
Before you begin
You need access to the Manager installation folder on the Manager server to view the
generated .csv file.
Task
1
Log on to the Manager using a supported browser.
2
After successful logon, duplicate the Manager session.
For example, open the same browser that you used to log on in the previous step and enter the
Manager URL.
3
In the duplicate Manager session, enter the following URL: https://<Manager server IP or
name>/intruvert/device_profile_csv.jsp
If the script runs successfully, a message is displayed in the browser.
Figure 13-5 Running the device-profile script
4
In the Manager server, go to <Network Security Manager install folder>\App and open
the .csv file named device_profile_<time stamp>.csv.
Figure 13-6 Device profiles in a .csv file
•
Host IP: This is the IP address of the host. Only one row is maintained per IP address.
•
Device: This is the type of the host. General Purpose Computing Device refers to desktops,
laptops, and so on. Some other types are Android Device, Apple iOS Device, and HTC Device.
•
OS: This is the operating system detected on the host.
•
Source: This refers to the source of the profile - IPS Sensor, NTBA Appliance, or ePolicy
Orchestrator
•
Creation Time: The time the host was profiled first.
•
Last Modification Time: The time when the profile was last updated.
McAfee Network Security Platform 8.1
IPS Administration Guide
351
13
Device Profiling and Alert Relevance
Alert relevance
Troubleshooting for device profiling
This section includes troubleshooting that is specific to device profiling in IPS, ePolicy Orchestrator,
and NTBA.
Operating system or device does not match
When you are using ePolicy Orchestrator for device profiling and encounter a situation in which the
operating system or device type details do not match the actual system details, check the ePolicy
Orchestrator console to know whether the operating system and device type information is correct
here.
•
If the information displayed here is incorrect, refer the McAfee® ePolicy Orchestrator® 4.6.0
Software Product Guide.
•
If the information displayed here is correct, to the <app folder> for the Manager and open dpinfo
.log or ePO.log.
The logging to ePO.log will not be enabled by default. To enable this refer section Enable ePO.log.
Alert relevance
When you see an alert in the Real-Time Threat Analyzer, you are being shown the details pertinent to
an attack attempt. One of the factors that can help you make a decision on whether or not to act is
the result of the attack. Ultimately, it is the relevance of the attack that can assist you with this
decision.
Alert relevance or relevance is the extent to which the alert generated is relevant and is defined
numerically and is calculated for signature based attacks.
Relevance is a score that is displayed in the Real-Time Threat Analyzer Alerts tab under a separate
column labeled Relevance.
The Relevance column is hidden by default and will need to be enabled manually.
Figure 13-7 Relevance column in the Real-Time Threat Analyzer
352
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Alert relevance
13
Relevance is represented as a percentage of relevance of an alert to the target host. It ranges from
0% to 100% and has a set of sub-ranges–each with a specific color to represent the perception of
threat from the attack. The calculation of the relevance score is based on a logic that is discussed in
depth further on. Below is a list of the sub-ranges, values, and their representative color codes as
displayed in the Relevance column of the Threat-Analyzer:
This color...
Refers to this relevance range...
0% - 20%
21% - 40%
41% - 60%
61% - 80%
81% - 100%
Alert relevance is computed based on certain factors and is updated each time a signature set is
updated. It is carried out within the Sensor and Manager in a preset order, which is not customizable.
The diagram below illustrates this systematic approach to determining alert relevance.
Figure 13-8 Flow to determine Alert Relevance
The following sections discuss is sequential order the method by which the relevance is computed:
1
Attack result – The first parameter considered is the result of an attack. If the attack result is
"Attack Successful", the attack is relevant and the score is 100%. If the attack result is "Attack
Failed", the attack is not relevant and the score is 0%.
To compute the attack result, the Sensor also extracts browser information from the User Agent
field. This information is used by Manager to evaluate relevance of an attack, since each attack has
the ability or is designed to compromise only certain browsers. However, for browser information to
be considered in calculating relevance, device profiling using HTTP data and alert relevance need to
be enabled in the Manager.
If the attack is not relevant for a browser, the result of the attack will be set to "Attack Failed" and
the relevance is 0%. But if the attack is not found to match the browser, the algorithm proceeds to
establish other details mentioned further in this section.
If the Sensor is not able to clearly establish browser information, the alert relevance based on the
browser cannot be computed.
McAfee Network Security Platform 8.1
IPS Administration Guide
353
13
Device Profiling and Alert Relevance
Alert relevance
If the attack result is anything other than "Attack Successful" or "Attack Failed", that is, the
Manager did not receive conclusive result from the Sensor, the Manager refers to the next source.
There are certain prerequisites to consider browser relevance. These are:
2
•
Device profiling using the HTTP technique is enabled and
•
HTTP traffic must contain the corresponding User Agent fields.
McAfee Vulnerability Manager – If you have integrated Vulnerability Manager with the Manager,
you have the option to enable the use of vulnerability scan results to calculate relevance. If you
have chosen to use this information, the Manager will either actively query Vulnerability Manager or
passively receive this information. The response will be relevant, not relevant, or unknown, which
would mean either 100% or 0% in the Relevance column. If the Vulnerability Manager is unaware
of the relevance of the attack, the Manager looks to the next source of information. For details
about Vulnerability Manager, see Section Integration with McAfee Vulnerability Manager in the
Network Security Platform 7.5 Integration Guide.
Manager
3
Operating system based relevance – The operating system of the destination host is important
to the relevance of an alert since every attack can compromise only certain operating systems.
The operating system is deciphered by Device Profiling, which is another feature of Network Security
Platform. To learn more about device profiling, refer section Device Profiling.
Examples:
•
A destination host is running on Linux platform. An attack that is detected is known to be
capable of attacking a system running on a Windows platform. In this situation, the attack
would not be relevant to the host.
•
A destination host is running Windows XP SP1. An attack that is detected is known to be capable
of attacking Windows XP SP1, SP2, and SP3. This attack would be relevant to the host.
The relevance scoring algorithm
Common Platform Enumeration to identify vulnerable systems
If the operating system does not completely match, the result of the attack is inconclusive. In such
circumstances, the Manager assigns a partial relevance score by way of a scoring algorithm. Scoring
relies on the matching each component of the Common Platform Enumeration (CPE) name of attack
signature with CPE name of the target system. CPE™ is a standardized method of describing and
identifying classes of applications, operating systems, and hardware devices present among an
enterprise's computing assets. CPE can be used as a source of information for enforcing and verifying
IT management policies relating to these assets, such as the vulnerability of a target system to a
malicious attack. Network Security Platform collects information about servers, workstations and other
devices on the network, identifies these products using their CPE names, and uses this standardized
information when matching the CPE of the attack signature to the CPE of each device. For more
information on CPE, you can go to http://cpe.mitre.org.
CPEs are represented in a certain order and with a specific syntax. The universal CPE format is
represented in the figure.
Figure 13-9 CPE Format
354
McAfee Network Security Platform 8.1
IPS Administration Guide
13
Device Profiling and Alert Relevance
Alert relevance
How CPE influences the relevance score
Each component in the CPE is given a specific weight depending on the potential of that component to
contribute to the vulnerability of the system. The table below presents the various components in the
CPE that are used to compute the relevance score:
Table 13-2 Components of a CPE and their weights
This components... Signifies this...
Carries a
weight of...
Part
0
First component in the CPE, which is a single letter code that
designates the particular platform part that is being identified.
The following codes are defined for the part:
• h – hardware part
• o – operating system part
• a – application part
Vendor
Second component in the CPE name, which refers supplier or
vendor of the platform part. Example: Microsoft, Redhat, etc.
10
Product
Third component in the CPE name, which refers a specific
product developed by the vendor. Example: Windows XP,
Windows NT, Enterprise Linux, etc.
30
Version
Fourth component in the CPE name, which refers to a specific
version of the product. Example: 4.0 for Window NT, 4 for
Enterprise Linux, etc.
20
Update
Fifth component in the CPE name, which refers to a specific
20
update of the version. Example: SP6 for Wndows NT, Update 4
for Enterprise Linux, etc.
Edition
Sixth component in the CPE name, which refers to the edition
of the product. Example: Workstation, Server, etc.
15
Language
Seventh component of the CPE name, which refers to the
language of the product. Example: English, Spanish, etc.
5
The illustrative diagram below shows you the format and correlates it with real world products and in
turn with weights as displayed in the table above.
Figure 13-10 CPE Illustration
A few other examples of CPEs include:
McAfee Network Security Platform 8.1
IPS Administration Guide
355
13
Device Profiling and Alert Relevance
Alert relevance
•
cpe:/o:microsoft:windows_xp:::pro
•
cpe:/a:adobe:reader:8.1
•
cpe:/o:redhat:enterprise_linux:4:update4
CPE name matching logic
To compute the relevance score, the CPE of the attack signature is matched with every component of
the CPE of the target system. If any component is not mentioned in the attack signature CPE, it
applies to all instances that can occupy that position. For example cpe:/o:microsoft:windows_xp
applies to all versions, updates, editions, and languages of Microsoft Windows XP.
A CPE match is considered definitive.
A few more examples to illustrate the name matching logic are presented below:
•
•
Case 1 – cpe:/o:microsoft:windows:xp will match all the operating system variants mentioned
below:
•
cpe:/o:microsoft:windows:xp::sp1
•
cpe:/o:microsoft:windows:xp::sp1:
professional
•
cpe:/o:microsoft:windows:xp::sp2
•
cpe:/o:microsoft:windows:xp::sp1::e
n
•
cpe:/o:microsoft:windows:xp
Case 2 – cpe:/o:microsoft:windows:xp::sp1 will not match cpe:/o:microsoft:windows:xp::s
p2 because not all parameters of the attack signature CPE match the target system CPE.
Scenarios to understand score computation
Refer to the table below to view some scenarios for alert relevance scoring.
356
McAfee Network Security Platform 8.1
IPS Administration Guide
13
Device Profiling and Alert Relevance
Alert relevance
Table 13-3 Illustrating relevance score calculation through examples
Attack
Description of the Target system
signature CPE attack signature
CPE
CPE
cpe:/o:
microsoft:
windows_xp::s
p2
This attack is
relevant to all
Microsoft Windows
XP SP2 systems,
irrespective of
which version,
edition, and
language they use.
How the two CPEs match
up
Relevance
score
cpe:/o:
microsoft:
windows_xp::s
p2:professional
Since the CPE from the
attack signature is
considered definitive, and all
components of the target
system CPE match the
components of the attack
signature CPE, the alert
generated is 100% relevant.
100%
cpe:/o:
microsoft:
windows_xp
Since the CPE from the
attack signature is
considered definitive, and
only the {part}, {vendor},
and {product} components
of the attack signature CPE,
and not the {update}
component, matches the
target system CPE, the alert
generated has a relevance
of 100 - 20 = 80%.
80%
cpe:/o:
Since the CPE from the
microsoft:
attack signature is
windows_xp::sp3 considered definitive, and
the {part}, {vendor}, and
{product} components of
the attack signature CPE
match that of the target
system CPE, the alert might
initially appear relevant.
However, notice that the
{update} component of the
target system CPE is present
but different than that of the
attack signature CPE. This
means that the alert
generated will not be
relevant and the score will
be 0%.
McAfee Network Security Platform 8.1
0%
IPS Administration Guide
357
13
Device Profiling and Alert Relevance
Alert relevance
Special scenarios in which the relevance score is computed
•
In day-to-day operations, not every attack that is mounted and consequently every attack
signature CPE that is extracted is as straightforward as those that are mentioned above. In some
cases of device profiling a thorough analysis might not be possible. As a result, device profiling
does not isolate the operating system and presents a possibility of more than one operating
system. The relevance score is calculated by as the average relevance score of all the matched
CPEs.
Presented in the table below are some such scenarios where the relevance score is computed for a
group of CPEs.
Figure 13-11 Representation of a group CPE
Table 13-4 Illustrating relevance score calculation for group CPEs through examples
Host group CPE Maps to individual
CPEs
CPE match
scenarios
Relevance score
logic
Relevance
score
cpe:/o:
microsoft:
windows_2000
_windows_xp
_windows_2003
Case 1: All CPEs
match
cpe:/o:microsoft:
windows_xp
Since all the CPEs
match, the
relevance score is
computed as the
maximum.
100%
Since only two of
three CPEs match,
the score will be
computed as
200/3 = 66%.
66%
Since only one of
three CPEs
matches, the
score will be
computed as
100/3 = 33%.
33%
Since only two of
three CPEs match,
the score will be
computed as
200/3 = 66%.
66%
cpe:/o:microsoft:
windows_xp
cpe:/o:microsoft:
windows_2000
cpe:/o:microsoft:
windows_server
_2003
cpe:/o:microsoft:
windows_2000
cpe:/o:microsoft:
windows_server
_2003
Case 2: Two CPEs
match
cpe:/o:microsoft:
windows_xp
cpe:/o:microsoft:
windows_server
_2000
Case 3: One CPE
matches
cpe:/o:microsoft:
windows_xp
cpe:/o:microsoft:
windows_server
_2008
Case 4: Two CPEs
match
cpe:/o:microsoft:
windows_xp
cpe:/o:microsoft:
windows_server
_2000
cpe:/o:microsoft:
windows_server
_2008
358
McAfee Network Security Platform 8.1
IPS Administration Guide
Device Profiling and Alert Relevance
Alert relevance
•
13
There are also cases when conventional methods of calculating a relevance score are not able to
provide a score. This is especially noticed when the exact details of the operating system are not
available. It can also be noticed when the attack is being launched through an application and
details of the application are not available. In such instances, the Manager relies on the attack
signature to be able to provide you more clarity.
The Manager determines the vulnerable application and uses the signature to decipher the
operating system it is compatible with. It then compares this operating system to the target
operating system. If the two match, a default score of 50% is displayed. If the two do not match, a
score of 0% is displayed. For example, if the application is one that runs only on a Linux-based
operating system but the attack is directed at a system running Microsoft Windows, the attack will
not be relevant. Or assume that the attack is one that exploits a vulnerability in Microsoft Word
(which is assumed to only be compatible with Microsoft Windows) and the target environment is
running some Microsoft product, a default score of 50% will be displayed, prompting you to further
investigate.
Special circumstances
Your network may have specific settings or deployments that affect the way in which alert relevance
work. The following scenarios discuss this:
•
Management disaster recovery (MDR) – If your network is configured for management disaster
recovery, the relevance is calculated separately in each of the Managers.
•
Simulated blocking – In case an attack is blocked, the alert relevance will be calculated using
target host details i.e., McAfee Vulnerability Manager and operating system data. The same steps
will be followed for Simulated Blocking.
Enable alert relevance
By default, you will find alert relevance enabled in the Manager. If you want to alter alert relevance
settings in the Manager at any time, perform the following steps.
Task
1
Select Manage | <Admin Domain Name> | Troubleshooting | Alert Relevance.
The Alert Relevance page appears.
2
Select the Alert Relevance Analysis? checkbox.
3
Click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
359
13
Device Profiling and Alert Relevance
Alert relevance
360
McAfee Network Security Platform 8.1
IPS Administration Guide
14
Advanced Malware Policies
Modern advanced malware based attacks pose acute security threats to enterprises. McAfee Network
Security Platform provides several features to detect and prevent the advanced threats prior to
infection. You can also detect post infection by monitoring the bot command and control server
activity. Network Security Platform provides visibility across multiple network vectors (host, IP, user,
and so on) and the ability to correlate this information over a period of time. Once a threat is
identified, understanding the root cause and exposure are critical to avoid similar threats in the future.
The primary functionality of the Advanced Malware Protection feature is to provide a prioritized list of hosts
that need remediation based on a risk score determined on a set of threat vectors and events
correlated over time.
How an Advanced Malware policy works
A malware policy, is a set of rules that scans the traffic across your network, and determines how to
respond to malware detected in the network. An effective policy is one that is customized to the
network environment being monitored.
A McAfee malware policy is a set of rules that define the traffic to be scanned for the detection of
malware and how you want to respond if the malicious activity is detected. Creating a policy enables
you to define an environment to protect by the different operating systems, applications, and
protocols in your network. These parameters, or rules, relate to all of the attacks defended against by
Network Security Platform.
Figure 14-1 Advanced malware detection
McAfee Network Security Platform 8.1
IPS Administration Guide
361
14
Advanced Malware Policies
There are various components of a malware policy. The malware policy allows you to select the
Protocols to Scan. You can select the protocol streams which are monitored by the Sensor according to
the configured malware policy. The Sensor can extract files from the HTTP and SMTP traffic for
scanning. Specific File Type in the HTTP and SMTP data streams can be scanned. Select the file type
based on the kind of traffic your network experiences. Various Malware Engines are supported to scan the
selected file types in the network traffic. You can configure one or more supported engines for a
specific file type. After the scanning is complete, these engines report a certain confidence level for
the scanned file. The confidence level is based on the specificity and severity of the malware and is
indicative of the extent to which the file is infected, for example, a high confidence level indicates a
high probability of the file being infected. Based on the confidence level returned the Action Thresholds
are set to be triggered. You can remediate the threat through configured response actions like
blocking and quarantining infected hosts, stopping malicious file download and identifying hosts with a
high threat score through the dashboard. You can prevent the malware from reaching the host by
blocking it or sending TCP resets. You can analyze malware using the malware dashboards. The
malware dashboards allow you to drill down into each piece of detected malware. The Malware Downloads
page provides you with more details of the detected malware. You can also save the malicious file and
submit it for analysis.
The supported parameters for a malware policy are:
•
File Type: Executables, MS Office Files, PDF Files, Compressed Files, Android Application Package and
Java Archive.
•
Malware Engines: Black and white lists, GTI File Reputation, PDF Emulation, NTBA, and Advanced
Threat Defense.
•
Action Thresholds: Alert, Block, Send TCP Reset, Add to Blacklist, and Save File.
Consider the following example.
•
The Sensor is deployed in the inline mode. Monitoring ports 1A and 1B inspect traffic flowing
between router A and router B.
•
Create an Advanced Malware policy, Malware Policy_1 with the following PDF malware rule enabled
for SMTP traffic and push the policy to the Sensor.
•
File Type: PDF
•
Malware Engine: PDF Emulation
•
Action Thresholds: For "Very low", "low" and "medium" confidence level returned, the configured
action is to generate an "Alert".
For "High" and "Very high" confidence levels, the configured response action is to "Block" and
"Send TCP Reset".
•
362
Configure the malicious file to be saved for analysis.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
•
14
Assign the policy to both inbound and outbound traffic and to the available interfaces (in this case
to ports 1A and 1B), according to your requirement.
Figure 14-2 Advanced malware detection using PDF Emulation
•
The PDF files are extracted from the SMTP data streams and scanned by the PDF Emulation engine.
The engine detects a Base64 encoded PDF file.
•
Based on the severity and the extent to which the file is infected the PDF Emulation engine returns
a confidence level. In this case, the confidence level returned is "high". An alert is raised in the
Threat Analyzer.
•
As defined by the malware policy, the response action is triggered for a "high" confidence level. The
detected malware infected data packets are dropped. Thus malicious files are prevented from
reaching the host.
•
You can drill down and analyze the infected hosts and the malware details through the various
dashboards.
Consider some variation to the above example and have multiple engines configured, namely, NTBA,
PDF Emulation, and GTI File Reputation. Multiple engines report varying confidence levels; PDF
Emulation and GTI File Reputation report a low confidence level while NTBA reports a high confidence
McAfee Network Security Platform 8.1
IPS Administration Guide
363
14
Advanced Malware Policies
level. In such a scenario, the highest confidence level returned is considered by the Network Security
Platform for its response action. In this case based on the high confidence level returned by the NTBA
engine, traffic is blocked.
Figure 14-3 Advanced malware detection using multiple engines
McAfee advises you to create multiple, specific policies that focus on the specific needs of unique
zones in your network, rather than a one-size-fits-all policy for the entire network.
•
GTI File Reputation
Network Security Platform integrates with McAfee GTI File Reputation [formerly McAfee Artemis
technology], which is a cloud‑based service that provides real‑time protection from malicious file
downloads.
For more information on McAfee GTI File Reputation see Network Security Platform Integration
Guide.
GTI File Reputation scans the selected file type for potential malware including encoded files. The
Sensor creates a fingerprint (MD5 hash value) of the file that is seen as potentially malicious,
embeds the fingerprint in a standard DNS request, and sends it to McAfee GTI cloud server. The
cloud server compares the fingerprint against the threat database maintained by McAfee Labs. If
the fingerprint is identified as a known malware, the cloud server notifies from the Sensor and it
enforces a response action for the malware.
•
Blacklist and Whitelist
Network Security Platform also provides users the option to upload custom fingerprints to the
Manager, which can be used for file reputation instead of GTI lookups or to complement them. The
Manager then sends these fingerprints to the Sensors.
364
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
14
You can add the MD5 hash values of known malicious files to the blacklist; add the MD5 hash
values of trusted files to the whitelist. The Sensor scans the specified file types for potential
malware, including encoded files, and compares it with custom fingerprints. This enables the
Sensor to immediately identify known malware and also identify the trusted files, without having to
analyze such files further. This saves both time and valuable Sensor resources.
The Sensor checks the whitelist before the blacklist.
If a match is found in the blacklist, it enforces a response action. It can also be configured per
interface. Note the following when custom fingerprints is configured among multiple engines.
•
When multiple engines are selected, whitelist and blacklist get the highest priority. It is the first
engine to scan the file.
•
If the scanned file finds a match in the whitelist, the file is considered to be clean.
•
If the scanned file finds a match in the blacklist, none of the other configured engines scan the
file. A confidence level of Very High is returned and the configured response action is triggered.
•
If the scanned file does not find a match in the white or black list, other applicable engines
concurrently scan the file. The highest confidence level returned is considered for the response
action.
For more information on black and white lists, see the Network Security Platform Integration Guide.
•
PDF Emulation
The Sensor has a PDF-JavaScript engine which scans the PDF files for potential malware. This
engine has a PDF analysis component which extracts JavaScript in the PDF, and a JavaScript
analysis component which executes the extracted JavaScript and uses heuristics to detect attacks.
Once the processing is done and if any malicious content is found, the Sensor sends an alert to the
Manager. Based on the confidence level returned the configured response action takes place.
McAfee Network Security Platform 8.1
IPS Administration Guide
365
14
Advanced Malware Policies
•
NTBA
The NTBA appliance has the McAfee Gateway Anti-Malware Engine running on it. The IPS Sensor
sends the file with potential malware to NTBA, which scans it using this engine and sends the
results (confidence level) back to the IPS Sensor. The Sensor sends the alert to the Manager and
the configured response action takes place.
The McAfee Gateway Anti-Malware Engine is a multi-platform engine that detects and blocks
malware threats — everything from viruses and worms to adware, spyware, and riskware. To
further protect end users against emerging malware threats, zero-day threats, and targeted
attacks, the McAfee Gateway Anti-Malware Engine focuses on generic and heuristic detection of
malware.
•
Advanced Threat Defense
McAfee Advanced Threat Defense is an on-premise appliance that facilitates detection and
prevention of malware. McAfee Advanced Threat Defense provides protection from known,
near-zero day, and zero-day malware without compromising on the quality of service to your
network users.
The McAfee Advanced Threat Defense solution primarily consists of the McAfee Advanced Threat
Defense appliance and its pre-installed software. The McAfee Advanced Threat Defense appliance is
available in two models. The low-end model is the ATD-3000. The high-end model is ATD-6000. For
complete information on McAfee Advanced Threat Defense, see the McAfee Advanced Threat
Defense Product Guide.
You can integrate McAfee Advanced Threat Defense with Network Security Platform. After you
integrate, both the Sensor and the Manager communicate with McAfee Advanced Threat Defense
separately to augment your defense against malware. This integration enables you to analyze files,
366
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
14
for at least known malware, before they are downloaded into your network. For detailed
information on how to configure this integration, see the Network Security Platform Integration
Guide.
Figure 14-4 Integration with McAfee Advanced Threat Defense
When you integrate with McAfee Advanced Threat Defense, Advanced Threat Defense is available
as an additional malware engine for all the supported file types in the Advanced Malware Policies.
You can select this engine along with any of the other malware engines except NTBA. Because
McAfee Gateway Anti-Malware Engine is available in both McAfee Advanced Threat Defense and
NTBA appliance, you can only select either of these engines for a file type.
The Sensor's black and white lists are different from the black and white lists of McAfee Advanced
Threat Defense.
Based on the configuration, an inline Sensor detects a file download. If the file is not listed in the
black or white list, it sends a copy of the file to the applicable malware engines, including McAfee
Advanced Threat Defense. If McAfee Advanced Threat Defense is able to detect a malware in real
time, the Sensor blocks the download. If McAfee Advanced Threat Defense requires more time for
analysis, the Sensor allows the file to be downloaded. If McAfee Advanced Threat Defense detects a
malware after the file has been downloaded, it informs Network Security Platform, and you can use
the Sensor to quarantine the host. Then, you can enforce remediation before allowing the host to
come back online. If the same malicious file is downloaded again, the Sensor itself blocks it since it
McAfee Network Security Platform 8.1
IPS Administration Guide
367
14
Advanced Malware Policies
now has the information about that file. For detailed information on how this integration prevents
known and unknown malware from entering you network, see the Network Security Platform
Integration Guide.
McAfee GTI File Reputation is available both in the Advanced Malware policies in the Manager as well
as in McAfee Advanced Threat Defense. However, McAfee recommends that you use the Advanced
Malware policy for this feature. The Sensor can respond quicker if it is configured in the Advanced
Malware policy because, in this case, it directly communicates with McAfee GTI.
•
Packet hold timeout — This is the 6-second period per file for which the Sensor holds the last
packet of the file before forwarding it through the egress port. The Sensor holds this packet until
there is a report from all the configured malware engines. After this timeout, the Sensor takes the
corresponding response action based on the results from those engines that responded within this
timeout. If none of the engines responded within this timeout, the Sensor forwards the last packet
without taking the response actions (block or TCP reset).
•
File session timout — This is the 5-minute period that the Sensor waits for a file to download. If the
file download exceeds this time interval, the Sensor does not enforce the Advanced Malware policy
for that file.
•
File scan timeout — This is the time period for which the Sensor honors results from the configured
malware engines. Any update from the engines after this time period are ignored. If PDF Emulation or
Save File is configured, then the file scan timeout is 90 seconds from when the Sensor sent the file to
the configured engines. If PDF Emulation or Save File is not configured, then it is 30 seconds.
File extraction does not work when HTTP response is chunk encoded or Gzip compressed.
You can view the malware engine and the malware file statistics using the commands show
malwareengine stats and show malwarefile stats.
Certain browsers or Smart downloaders continue to try to download file. Therefore, if you are not using
the RFB policy, enable blocking of the “HTTP: Repeated Download Detected” attack.
Network Security Platform allows you to detect malware in the monitored traffic by configuring a
malware policy, suited for your enterprise/environment, in the Manager. The malware policy can be
configured per interface. The policy can be configured for both inbound and outbound traffic. The
same policy can be applied to both, or, separate policies can be applied to inbound and outbound
traffic.
When a 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.
•
McAfee recommends the following for optimum performance.
•
The Advanced Malware policies be configured only on the external (internet facing
Sensors) and not on the internal ones.
•
Save malicious files, only if the number of files traversing the network is huge. Also,
save files with a "high" or "very high" confidence level. Avoid using the "Always" save
option.
PDF emulation on the Sensor is slower than on NTBA. For high volume deployments
enable PDF detection only on NTBA using GAM engine.
•
368
When Advanced Malware policies are configured there is a performance impact of up to 6
seconds on both the Sensor and the Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Add an Advanced Malware policy
14
Contents
Add an Advanced Malware policy
Manage Advanced Malware policies
Analyze Malware Detections
Archive malware files
Add an Advanced Malware policy
You configure the anti-malware options in an Advanced Malware policy and then assign it to the
required Sensor monitoring resources such as ports, interfaces, and subinterfaces. You must do a
configuration and signature set update for any changes in the policy to take effect.
Task
1
Select Policy and then select the required admin domain from the Domain drop-down list.
2
Select Intrusion Prevention | Advanced Malware | Advanced Malware Policies.
3
Click New.
The New Policy page opens.
Figure 14-5 Update the properties of the Advanced Malware policy
4
Update the following properties.
Field name
Description
Name
Name of the policy.
Description
Description of the policy.
Visible to Child Admin Domains? Specifies whether the policy is applicable to all child admin domains.
Protocols to Scan
Protocols over which advanced malware scanning is performed. The
supported protocols are HTTP and SMTP.
Enable HTTP Response scanning to scan files in the HTTP data stream.
McAfee Network Security Platform 8.1
IPS Administration Guide
369
14
Advanced Malware Policies
Add an Advanced Malware policy
5
Update the Scanning Options.
Figure 14-6 Update the scanning options of the Advanced Malware policy
Name resolution must be enabled on devices which will be using the GTI File Reputation malware
engine.
Field
name
Description
File Type
The file types to be scanned. The supported file types are:
• Executables (.exe, .dll, .scr, .ocx, .sys, .com, .drv, .cpl)
• MS Office Files (.doc, .docx, .xls, .xlsx. .ppt, .pptx)
• PDF Files
• Compressed Files (.zip, .rar)
• Android Application Package (.apk)
• Java Archive (.jar)
McAfee may enhance the supported file types over time. The file types are subject to
change with new signature sets.
.apk files are not supported for SMTP traffic.
Maximum
File Size
(KB)
Scanned
This the maximum size currently supported for the corresponding file type. Files that
exceed the specified size are not analyzed for malware by any of the engines,
including the black and white lists.
The default values are displayed in the Default Malware Policy as well as when you
create a policy. The default values are the optimum sizes recommended by McAfee
Labs based on their research on malware.
You can set the maximum file size value as up to 25 MB for all file types. However, the
PDF Emulation engine supports file sizes only up to 5 MB. Therefore, PDF files greater
than 5 MB are not analyzed by the PDF Emulation engine.
McAfee recommends that for any file type, you do not set a value more than 5 MB as
the maximum file size as this might affect the Sensor's performance.
370
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Add an Advanced Malware policy
14
Field
name
Description
Malware
Engines
The Malware engines to scan the selected file type. For a File Type, you can select either
NTBA or Advanced Threat Defense.
For Advanced Threat Defense to work, you must integrate the corresponding Sensors with
McAfee Advanced Threat Defense. See the Network Security Platform Integration
Guide for information.
Action
Thresholds
Specifies the type of response to be made for the attack. The types of responses are:
• Alert— Alerts are raised in the Threat Analyzer.
• Block— This action blocks packets for detected malware. Thus preventing the
malicious file from reaching the host.
The first step towards prevention is typically to block attacks that have a high
severity level. When you know which attacks you want to block, you can configure
your policy to perform the drop attack packets response for those attacks. If not
configured in the policy, the Threat Analyzer allows you to block traffic.
• Send TCP Reset— Disconnects a TCP connection at the source, destination, or both
ends of the transmission. Thus preventing the malicious file from reaching the host.
This response may not work effectively with SPAN and tap deployments.
• Add to Blacklist— If any of the engines report the submitted file to be malicious, then
the Manager adds the file's MD5 hash to the blacklist in its database. To be added to
this list, the file's severity must be the same or more than what you specify in this
field. For example, if you specify high as the criteria, then files of severity high and
very high are added to the blacklist. Within the next 5 minutes, the Manager adds
this file to the local blacklist of all the Sensors that it manages.
• Save File— One of the response actions specified is the ability to archive the file in a
file store based on the Advanced Malware policy. The files that are selected based on
this configuration are forwarded to Manager.
• For files greater than 5 MB, only the first 5 MB is available as the saved file.
• To prevent the Manager's disk from getting frequently filled up, use the Save File
feature sparingly.
• If McAfee Advanced Threat Defense is integrated, then note that McAfee Advanced
Threat Defense does not provide you access to the original sample files that it
analyzed. Therefore, you must use the Save File option, if you need to archive the
samples that a Sensor submits to McAfee Advanced Threat Defense. However,
note that the Sensor's simultaneous file scan capacity is reduced if the Save File
option is enabled. See the table in this section for the details.
Each file type is scanned by a Malware engine. Multiple malware engines can be selected to scan
various file types. The Malware engines return a confidence level. Based on the confidence level,
the following action thresholds can be set. The confidence levels supported are: Very low, low,
medium, high, very high.
The Malware Engines supported per file type are:
File Type
GTI File
Reputation
Local
Blacklist
Executables
x
x
x
x
x
x
x
x
x
x
x
MS Office Files
PDF Files
x
Compressed Files
McAfee Network Security Platform 8.1
x
PDF
Emulation
x
NTBA Advanced
Threat Defense
IPS Administration Guide
371
14
Advanced Malware Policies
Manage Advanced Malware policies
File Type
GTI File
Reputation
Local
Blacklist
Android Application
Package
x
x
Java Archive
PDF
Emulation
NTBA Advanced
Threat Defense
x
x
x
x
The maximum simultaneous file scan capacity per Sensor model is as follows.
Sensor
Maximum simultaneous file Maximum simultaneous file
scan capacity with file save scan capacity without file
save
NS9300, NS9200, NS9100
50
4094
M-8000, M-6050, M-4050,
M-3050, M-8030, M-6030,
M-4030
50
1024
M-2750, M-2850, M-2950,
M-3030, IPS-VM600
32
1024
M-1250, M-1450, IPS-VM100
16
255
6
To assign the Advanced Malware Policy to the available interfaces and direction (Inbound,
Outbound), select Prompt for assignment after save.
7
Select the required interface from the Available Interfaces column and add it to the Selected Interfaces
column.
8
Click Save.
You are directed to the new policy window.
Manage Advanced Malware policies
You can perform the following operations on an existing Advanced Malware policy.
372
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Manage Advanced Malware policies
14
Operation
Description
View Advanced
Malware
policies
The Advanced Malware Policy page allows you to view the Malware policies that have
been assigned to the various resources of your Network Security Platform. Policies
are listed per the Sensor, interface, and subinterface. From the root admin domain,
you can see policies assigned to all child domains. For non-root parent domains, you
only see the assigned policies in your parent and child domains. For child domains,
you only see the policies assigned to the resources in your domain. Select Policy |
Advanced Malware Policy to view the assigned Malware policies.
Edit an
Advanced
Malware policy
Editing an Advanced Malware policy allows you to make the changes necessary to
match the policy with the traffic you are monitoring. Editing a policy permanently
changes that policy.
If you intend to make slight changes to a policy but want to save it under a different
name, try cloning an Advanced Malware policy.
1 Select Policy | Intrusion Prevention | Advanced Malware Policy.
The Advanced Malware policies are listed.
2 Select the policy to edit.
3 Click Edit.
4 Edit the policy parameters.
5 Click Save.
Clone an
Advanced
Malware policy
Cloning duplicates an existing policy, and is similar to a "save as" function. You can
edit aNetwork Security Platform-provided policy. However, if you want to edit a copy
of a policy, you can clone any existing policy to further refine the policy for
application in a new environment. You can clone a provided policy, save it under a
new name, and customize it for your unique environment.
1 Select Policy | Intrusion Prevention | Advanced Malware Policy.
The policies are listed.
2 Select the policy you want to clone.
3 Click Clone.
4 Type a new name for the policy, if required and edit the policy parameters.
Delete an
Advanced
Malware policy
To delete an Advanced Malware policy you have created.
1 Select Policy | Intrusion Prevention | Advanced Malware Policy.
The Advanced Malware policies are listed.
2 Select the policy to be deleted.
3 Click Delete.
4 Click Yes to confirm the deletion.
You cannot delete a currently applied policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
373
14
Advanced Malware Policies
Analyze Malware Detections
Operation
Description
Export an
Advanced
Malware policy
You can export and save one or more Advanced Malware policy into a file.
1 Select Policy | Intrusion Prevention | Advanced | Policy Export | Advanced Malware Policies.
The existing Advanced Malware policies are listed.
2 Select one or more policies to be exported.
3 Click Export. You are prompted to specify the location to save the file.
The policy is saved in an XML format in the specified location.
Import an
Advanced
Malware policy
You can import an Advanced Malware policy from a saved file.
1 Select Policy | Intrusion Prevention | Advanced | Policy Import | Advanced Malware Policies.
To skip importing duplicate policy definition, select Skip duplicate policy definitions.
2 Browse to the file location.
3 Click Import. The import status is displayed.
Analyze Malware Detections
You can leverage the analysis technique provided by Network Security Platform to perform an in-depth
analysis of the malware detected in your network. The Manager provides you with a complete view of
the malware and threats on your network for further analysis and actions thus providing a
comprehensive view of the threat landscape in your network. You can view the Top Malware Detections.
This dashboard is populated because a malicious file has been detected. The dashboards display the
File Hash and the Attack Count of the detected malware. The Dashboard page security monitors are
displayed as bar charts.
Figure 14-7 Top Malware Detections
If you want to drill down further on a specific malware, click on a bar, and you will be redirected to the
Analysis | Malware Detections page, which displays additional details on that malware. This page provides
you with the flexibility of filtering and sorting the information displayed based on your choice. In
addition to these filtering/sorting options, you can also view the alerts that match the filter criteria by
opening the Threat Analyzer Alerts page directly from the Threats Explorer. You can view the malware
detections specific to admin domains by selecting the required admin domain from the Domain
drop-down list. Summarized data for malware detections, which includes data from the child domains,
374
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Analyze Malware Detections
14
also can be viewed. If you have integrated the Manager with McAfee ePolicy Orchestrator, McAfee®
Logon Collector, or McAfee Vulnerability Manager, you can view the endpoint name, operating system,
open ports, and known vulnerabilities.
The following chart gives you the comprehensive analysis options provided by the Malware Detections
page. These tabs are explained in the subsequent sections.
Figure 14-8 Malware analysis
McAfee Network Security Platform 8.1
IPS Administration Guide
375
14
Advanced Malware Policies
Analyze Malware Detections
The following filter options are provided.
Figure 14-9 View data specific to admin domain
Figure 14-10 Analyze detected malware within a specific time
Figure 14-11 Analyze the type of malware, whether blocked, unblocked, or all
Figure 14-12 Details of the detected malware
376
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Analyze Malware Detections
Field name
Description
Hash
Displays the hash value of the file and the actions that you can take.
14
• Actions— Click Take action to take the following actions:
• Export— Click to download the malware file from the Manager server to a
network location. The file is saved with an extension .mcafee. This prevents you
from even accidentally opening the malicious file. The file is available for
download only if you enable the Save File option for the corresponding file type in
the Advanced Malware policy that detected this malware.
The antivirus program on your computer might prevent you from downloading
the file.
• Whitelist— Click to automatically add the file to the Manager's whitelist. In the
next 5 minutes, the manager sends the MD5 hash value to the whitelist of all
the Sensors.
• Blacklist— Click to automatically add the file to the Manager's blacklist. In the
next 5 minutes, the manager sends the MD5 hash value to the blacklist of all
the Sensors.
• Hash— Displays the MD5 hash of the file.
Overall Malware
Confidence
The overall malware confidence level returned by the configured malware scanning
engines.
Individual Engine
Confidence
The confidence level returned by each configured malware scanning engine,
Last Detection
The date and time the last malware was detected.
Total Detections
The number of times the malware was detected.
Last File Name
The name of the last saved malware file. In case of HTTP downloads it will be the
URL.
Last Result
The last response by the Sensor to the detected malware.
File Size (bytes)
The size of the malware file saved.
Comment
Additional comments on the detected malware.
individually. Click
to view the engine-specific details.
Select the malware whose details you want to view.
Field name Description
Time
The time when the malware was detected each time.
Attack
•
About— Click
to open the attack information and description for the malware.
• Attack— Click on the attack name to open the Threat Explorer for the attack.
• Result— The response by the Sensor to the detected malware.
• Direction— Indicates the direction of the malware traffic.
Attacker
The attacker IP Address and Country are displayed. Click the IP Address to view the
endpoint details.
Target
The target IP Address and Country are displayed. Click the IP Address to view the
endpoint details.
Protocol
Protocol over which the malware was detected. The possible values are HTTP and SMTP
since only these are supported for malware analysis.
Confidence
The malware severity level as reported by the malware engines. The possible values are
very low, low, medium, high, and very high. This value might vary between detections
for the same file because the malware engine involved could have been different.
McAfee Network Security Platform 8.1
IPS Administration Guide
377
14
Advanced Malware Policies
Analyze Malware Detections
Field name Description
File Name
The name of the saved malware file.
Engine
The configured scanning engine that detected the malware.
Device
The Sensor that detected the malware.
Threat Explorer
Threat Explorer allows you to explore threats endpoints as source and target IPs. For more
information see the section Threat Explorer.
Endpoint Information
The Endpoint Information sub-tab shows the following details specific to the endpoint.
Figure 14-13 Analyze Endpoint Information
Item
Description
DNS Name
DNS name of the endpoint to resolve the names to IP addresses.
NetBIOS
NetBIOS name of the endpoint to access the endpoint machines.
Operating system
Operating system platform of the endpoint.
Device Type
Device type of the attacker/target.
MAC Address
MAC address of the endpoint.
Country
Country of the endpoint.
Domain/Workgroup
Domain or workgroup of the endpoint.
User
Operating system user name of the endpoint.
Data Source
Database tables from where information is retrieved.
McAfee Agent Check-In
Time
Check-in time of the McAfee Agent that communicates with the same ePO
server integrated with the admin domain.
Endpoint Type
Type of the endpoints:
• UNMANAGED (No Agent)— This indicates that there is no McAfee Agent installed
on the endpoint.
• UNMANAGED (MANAGED)— This indicates that the endpoint has a McAfee Agent
but there is no active communication channel between the Agent and ePO
server integrated with the admin domain.
Installed products
378
List of the installed products.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Analyze Malware Detections
•
14
Network Forensics— Click this tab to analyze the network behavior of the endpoint when NTBA is
configured.
Figure 14-14 Network Forensics page
You can filter your view by choosing the time and date of your choice.
Figure 14-15 Date and time options in Network Forensics page
The Show option helps you to select the Root Cause Analysis and Exposure Analysis options to analyze the
network behavior of the endpoint within a specific time.
Figure 14-16 Show option
For more information, see section Analyze Network Forensics.
•
View Alerts and PCAPs— Use this option to analyze and view the alerts. Using this option your are
navigated to the Threat Analyzer.
•
Analyze as attacker IP— View the alerts where the endpoint is the source IP address.
•
Analyze as target IP— View the alerts where the endpoint is the destination IP address.
McAfee Network Security Platform 8.1
IPS Administration Guide
379
14
Advanced Malware Policies
Analyze Malware Detections
•
Quarantine— Use this option to block all the traffic originating from the specified IP address seen on
the selected device for the selected time.
Figure 14-17 Quarantine Endpoint dialog
To block the traffic:
1
Select the specific device of the endpoint whose traffic originating from the IP address you want
to block.
2
Select the quarantine duration from the drop-down list.
The IP address of the endpoint is selected by default as the Attacker IP Address core attribute is
already selected.
Vulnerability Assessment
The Vulnerability Assessment sub-tab displays the following details. You can only view this section when the
Vulnerability Manager is configured.
Figure 14-18 Vulnerability Assessment sub-tab
380
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Analyze Malware Detections
Item
14
Description
General Activity Displays information such as the overall criticality of the endpoint, time of the last scan
and name of the scan engine.
Open Ports
Information about the open ports like the description of the port, service running on
the port and the description.
Vulnerabilities
Vulnerability details such as the risk levels, the name and the CVE ID of the
vulnerability.
Endpoint Security Events
The Endpoint Security Events sub-tab displays the following details. You can only view this section when
McAfee ePolicy Orchestrator is configured.
Figure 14-19 Endpoint Security Events sub-tab
Item
Description
Latest Anti Virus
Events
The latest events including the date and time when the event was received by the
anti virus agent, the name of the threat that caused the event to appear, the type of
the threat that triggered the event, the action taken by the anti virus agent on the
reported event, the path to the affected file that caused the event and the method
used to detect the anti-virus event.
Latest Endpoint
The latest endpoint intrusion prevention events including the date and time when the
Intrusion
event was received by the Endpoint Intrusion Prevention agent, the name of the
Prevention Events signature that caused the event to appear, the severity level of the Endpoint Intrusion
Prevention event, the user at the time the event was initiated, the application process
that triggered the event, the Source IP address for the event and the reaction set to
take place when the event is triggered.
For more information, see McAfee Network Security Platform Integration Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
381
14
Advanced Malware Policies
Analyze Malware Detections
View the McAfee Advanced Threat Defense specific details for a
detected malware
Similar to viewing the specific details for other malware engines, you can also view the specific results
returned by McAfee Advanced Threat Defense. In the Malware Detections page, click
confidence level for Advanced Threat Defense.
next to the
Figure 14-20 Details returned by McAfee Advanced Threat Defense
Table 14-1 Field descriptions
382
Field
Description
Environment
The VM profile that was used by McAfee Advanced Threat Defense to dynamically
analyze the file. This indicates the operating system on which the file was
executed.
File Summary
The name of the file, its size, and hash values are displayed.
Malware Confidence
The highest malware severity returned by the components of McAfee Advanced
Threat Defense.
Malware Indicators
The summary of the reports from the various analysis methods employed by
McAfee Advanced Threat Defense.
Individual Engine
Results
This section lists the analysis methods available in McAfee Advanced Threat
Defense. Here, they are referred to as Engine. The severity level returned by each
method and the name for the malware are also displayed. If a particular method
is not used, it indicates that it is not selected in the analyzer profile used for the
Sensor.
Sandbox Analysis
Results
This section displays the details if the file was dynamically analyzed by McAfee
Advanced Threat Defense. This includes the details of the analyzer VM, the time
and duration of the dynamic analysis, behavior during dynamic analysis, and so
on.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Analyze Malware Detections
14
Table 14-1 Field descriptions (continued)
Field
Description
Download Full Analysis Downloads a zip file that contains all the reports for the malware from McAfee
Report
Advanced Threat Defense. This is equivalent to downloading the reports zip file
from the McAfee Advanced Threat Defense web application. This zip file contains
the reports for each analysis. The contents of this zip file are explained beneath
this table.
Open ATD Console
Click to open the logon page of the McAfee Advanced Threat Defense that
analyzed the file.
Close
Closes the Advanced Threat Defense Engine Results window.
Download the <file hash>.zip file to the desired location. The files in this zip are created and stored
with a standard naming convention. Based on the reports selected in the analyzer profile used for the
analysis, the zip contains the following results:
•
<file hash>_summary.html (.json, .txt, .xml). This is the same as the Analysis Summary report in
the McAfee Advanced Threat Defense web application. There are four file formats for the same
summary report in the zip file. The html and txt files are mainly for end-users to review the
analysis report. The .json and .xml files provide well-known malware behavior tags for high-level
programming script to extract key information.
•
<file hash>.log. This file captures the Windows user-level DLL API calling activities during dynamic
analysis. You must thoroughly examine this file to understand the complete API calling sequence as
well as the input and output parameters. This is the same as the User API Log report in the McAfee
Advanced Threat Defense web application.
•
<file hash>ntv.txt. This file captures the Windows native services API calling activities during
dynamic analysis.
•
<file hash>.txt. This file shows the PE header information of the submitted sample.
•
<file hash>_detail.asm. This is the same as the Disassembly Results report in the McAfee
Advanced Threat Defense web application. This file contains reverse-engineering disassembly
listing of the sample after it has been unpacked or decrypted.
•
<file hash>_logicpath.gml. This file is the graphical representation of cross-reference of function
calls discovered during dynamic analysis. This is the same as the Logic Path Graph report in the
McAfee Advanced Threat Defense web application. Use a graph editor such as yWorks yEd Graph
Editor to view this file.
•
log.zip. This file contains all the run-time log files for all processes affected by the sample during
the dynamic analysis. If the sample generated any console output text, the output text messages is
captured in the ConsoleOutput.log file zipped up in the log.zip file. Use any regular unzip utility to
see the content of all files inside this log.zip file.
•
dump.zip. This file contains the memory dump (dump.bin) of binary code of the sample during
dynamic analysis. This file is password protected. The password is virus.
•
dropfiles.zip. This is the same as the Dropped Files report in the Analysis Results page of McAfee
Advanced Threat Defense web application. The dropfiles.zip file contains all files created or touched
by the sample during the dynamic analysis. It is also password protected like dump.zip.
For a detailed explanation of all these files and McAfee Advanced Threat Defense reports, see the
McAfee Advanced Threat Defense Product Guide.
McAfee Network Security Platform 8.1
IPS Administration Guide
383
14
Advanced Malware Policies
Analyze Malware Detections
Manager reports for malware detections
A default Next Generation Report called Top 10 Malware Detections provides details of the detected
malware. For a given time period, this report shows the alerts raised for the top 10 most frequently
downloaded malware in your network. Therefore, for a given file, you can view the results from
various malware engines. However, these results are dependant on the Advanced Malware policy
configuration for the period of the report.
Task
1
In the Manager select Analysis | Event Reporting | Next Generation Reports.
2
From the list of Saved Reports, select Default - Top 10 Malware Detections and then click Run.
3
Specify the time period for which you want to generate the report in the Date Options section.
4
Select the output format of the report from the Report Format list.
5
Click Run.
Figure 14-21 The default Top 10 Malware Detections report
The generated report is displayed.
Table 14-2 Column definitions
384
Column
Definition
Time
The time stamp when a malware engine determined the file to be malicious.
In other words, this is the time when the
Attack Name
The alert raised by the Sensor for the file.
Result
The response action taken by the Sensor for the file. For example, the Sensor
could have blocked the file download.
Src IP
The source IP address as seen in the traffic for the malware traffic.
Dest IP
The target host that is downloading the file.
Protocol
The L7 protocol involved. This could be HTTP or SMTP.
Device
The Sensor that detected the file download.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Archive malware files
14
Table 14-2 Column definitions (continued)
Column
Definition
File Hash
The MD5 hash value of the file as calculated by the Sensor.
Detection Engine
The malware engine that reported the malware.
File Malware Confidence The malware score reported by the malware engine.
Layer7 Data
The L7 data associated with the file.
The admin domain filter in the main Analysis page (provided in the left pane) has no impact on the
reports generated. The admin domain filter criteria selected for the reports, show data specific to
the admin domain selected.
•
For information how to use the Next Generation Reports, see Network Security Platform
Manager Administration Guide.
•
You can also generate a User Defined report using all of the above columns. For example, you
can generate a User Defined report that reports only very-high severity malware detected by
Sensors of a particular domain. You must use Alert Data as the Data Source when you define the
report. For more information on how to generate a User Defined report, see Network Security
Platform Manager Administration Guide.
Archive malware files
The malware policy has configuration settings to archive downloaded files based on various
characteristics. These downloaded files are archived on the Manager server. You can configure the
location and maximum disk space that can be used to store the archives. The configuration for disk
usage is defined at the Global Manager level. The Manager also provides configuration to prune files
that are stored for more than a specified period of time.
To maintain the malware files saved to the Manager.
Task
1
Select Manage | <Admin Domain Name> | Maintenance | Files | Malware archive.
2
The Storage Settings are displayed for each file type. Click on the Maximum Disk Space Usage Allowed to
modify it as per your requirement.
Figure 14-22 File storage settings
3
To prune the file storage click Automatic file pruning options.
File pruning option allows you to determine the interval at which the Manager prunes older data to
make sure its file system and database have adequate space for new data.
4
Click Save.
McAfee Network Security Platform 8.1
IPS Administration Guide
385
14
Advanced Malware Policies
Archive malware files
The Manager warns you when the allocated disk space to a malware file type reaches 70%, 80%,
90%, and 100% of the maximum allowed. When the maximum space limit is reached, new
malware files of that type are not stored until space is freed.
The default location of these files in the Manager server is Manager_Install_Directory\App\temp
\tftpin\malware. The list of files currently archived on the Manager are displayed with the
following details.
•
Time— Indicates the date and time when the file was saved.
•
About— Click to view details about the malware and how it infects the host. This is availabale for
PDF Emulation, NTBA, and Advanced Threat Defense engine results.
•
Actions— Click Take action to do the following:
•
Export— Click to download the malware file from the Manager server to a network location.
The file is saved with an extension .mcafee. This prevents you from even accidentally
opening the malicious file. The file is available for download only if you enable the Save File
option for the corresponding file type in the Advanced Malware policy that detected this
malware.
The antivirus program on your computer might prevent you from downloading the file.
•
Whitelist— Click to automatically add the file to the Manager's whitelist. In the next 5 minutes,
the manager sends the MD5 hash value to the whitelist of all the Sensors.
•
Blacklist— Click to automatically add the file to the Manager's blacklist. In the next 5 minutes,
the manager sends the MD5 hash value to the blacklist of all the Sensors.
This newly added hashes are appended to the existing list of whitelist or blacklist as applicable.
To view the current list of white and black lists, select Policy | root admin domain | Intrusion Prevention |
Advanced Malware | Whitelisted and Blacklisted Hashes.
•
Hash— Displays the MD5 hash of the file.
•
Type— The type of the saved file.
•
Size— The size of the file saved.
Figure 14-23 Details on stored files
5
To delete the archived files, select the required ones and click Delete.
Tasks
•
Add hash values to the whitelist on page 387
•
Add hash values to the blacklist on page 387
See also
Add hash values to the whitelist on page 387
Add hash values to the blacklist on page 387
386
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced Malware Policies
Archive malware files
14
Add hash values to the whitelist
You can add a list of whitelisted fingerprints (MD5 hashes) for files you want exempted from malware
analysis when found in HTTP or SMTP downloads.
Task
1
Select Devices | <Admin Domain> | Global | Default Device Settings | IPS Devices | File Reputation.
In the Whitelist section, you can add the hash values to be whitelisted.
2
Click Manage whitelisted hashes.
You can view the current list of whitelisted hashes.
3
Click Import to import a file containing the hash values.
4
Click Browse to locate an XML or CSV file that contains the list of hashes that you want to import.
5
Click Append or Replace depending on whether you want to append to the current whitelist or replace
it, and then click Import.
The following table describes about the details of the files to be imported in the CSV format.
Format
Description
<File name>
Specify the name of the file to be imported, along with the file extension.
<File size>
Specify the size of the file to be imported.
<Hash type>
Type MD5 to specify the hash type is MD5.
<File hash>
Specify the file hash.
<Description>
Type the description of the hash file.
The file to be imported should be in the following CSV format:
<Name of the file with extension (like .exe, .com)>,<File size>,<Hash type>,<File
hash>,<Description>
Example file format: Application.exe, 1024000, MD5, 30a4edd18db6dd6aaa20e3da93c5f425,
textual description. Also note that if you are importing multiple files, each file has to be in a new
line.
To export the whitelisted hashes from the Manager to a local system, click Export Whitelist.
6
To delete specific entries from the whitelist, select them by holding the Shift or Ctrl key and click
on the required rows. Then select Remove selected hashes (reset as Unclassified) from the Take action
drop-down list.
The deleted hashes are now neither in the whitelist nor in the blacklist.
7
To remove all the entries, select Remove all hashes (reset as Unclassified) from the Take action drop-down list.
8
To move specific entries to the blacklist, select the entries and then select Move selected hashes to
blacklist from the Take action drop-down list.
9
To move all entries to the blacklist, select Move all hashes to blacklist from the Take action drop-down list.
Add hash values to the blacklist
You can add MD5 hash values of files to treat as malicious when found in HTTP and SMTP downloads.
If a file's hash matches a hash value in the blacklist, the Sensor treats the file as malicious of very
high severity.
McAfee Network Security Platform 8.1
IPS Administration Guide
387
14
Advanced Malware Policies
Archive malware files
Task
1
Select Devices | <Admin Domain> | Global | Default Device Settings | IPS Devices | File Reputation.
In the Blacklist section, you can add the hash values to be blacklisted, manage the file types to be
checked for the blacklisted hashes, and view the maximum file size scanned.
2
Click Manage blacklisted hashes.
3
Click Import to import a file containing the hash values.
4
Click Browse to locate an XML or CSV file that contains the list of hashes that you want to import.
5
Click Append or Replace depending on whether you want to append to the current blacklist or replace
it, then click Import.
The following table describes the details of the files to be imported in the CSV or XML format.
Format
Description
<File name>
Specify the name of the file to be imported, along with the file extension.
<File size>
Specify the size of the file to be imported.
<Hash type>
Type MD5 to specify the hash type is MD5.
<File hash>
Specify the file hash.
<Description>
Type the description of the hash file.
The file to be imported should be in the following CSV format.
<Name of the file with extension (like .exe, .com)>,<File size>,<Hash type>,<File
hash>,<Description>
Example file format: Application.exe, 1024000, MD5, 30a4edd18db6dd6aaa20e3da93c5f425,
textual description. Also note that if you are importing multiple files, each file has to be in a new
line.
6
To export the blacklisted hashes from the Manager to a local system, click Export Blacklist.
7
To delete specific entries from the blacklist, select them by holding the Shift or Ctrl key and
clicking on the required rows. Then select Remove selected hashes (reset as Unclassified) from the Take action
drop-down list.
The deleted hashes are now neither in the whitelist nor in the blacklist.
8
To remove all the entries, select Remove all hashes (reset as Unclassified) from the Take action drop-down list.
9
To move specific entries to the whitelist, select the entries and then select Move selected hashes to
whitelist from the Take action drop-down list.
10 To move all entries to the whitelist, select Move all hashes to whitelist from the Take action drop-down list.
388
•
A manual signature set push in not required each time the whitelist or the blacklist is
updated. The Manager updates the Sensor dynamically with the modified entries in
the whitelist or blacklist, at an interval of 5 minutes. These updates occur in bulk (the
complete list of entries) or increments (added/deleted entries). To view the status of
these updates, use the show wb stats command. For more information, see the
McAfee Network Security Platform CLI Guide.
•
You can add a maximum of 100,000 entries (whitelist and blacklist).
McAfee Network Security Platform 8.1
IPS Administration Guide
15
Advanced botnet detection
Bot is defined as malicious software running on a compromised system that is designed to participate
in a centrally managed network of compromised computers known as a botnet. Single botnets have
been known to consist of over a million compromised computers, and are arguably the most
significant threats to the global Internet today.
Bot herders are moving away from massive botnets consisting of hundreds of thousands of zombies in
favor of smaller and more targeted ones. Additionally, the IRC protocol for command and control
(C&C) is being phased out in favor of more covert protocols, such as HTTP, non-SSL encrypted traffic
over port 443, and so on.
The bot-like behavior is usually identified in several phases (each identified by a single attack ID),
such as exploitation and infection, download of dropper files, download of configuration files, attack
and propagation, and so on. Each of the phases is typically carried out in a single network session. In
some of the cases, such network sessions may look benign too. Traditionally, an attack signature can
detect attack in a single flow except reconnaissance attacks. Network Security Platform supports
Advanced Botnet Detection by correlating multiple attacks across different flows. Attacks are
correlated by observing a host for a given period of time.
Advanced botnet detection provides detailed information retrieved from different attack phases at the
end of a successful correlation. Network Security Platform also forwards the attack information to the
NTBA appliance for doing similar correlation.
Contents
How the Advanced Botnet Detection Framework works
Configure Advanced Botnet Detection from the admin domain
Configure Advanced Botnet Detection at the interface level
Bot Command and Control server activity detection
How the Advanced Botnet Detection Framework works
The Advanced Botnet Detection framework provides an effective solution to detect and identify bot
infected machines in a network. It takes a two-fold approach to detect bots:
•
Correlate multiple different attacks being carried out in different network sessions.
•
Use a heuristic based approach that detects behaviors of bots.
This approach allows the framework to detect both known and 0-day bots.
McAfee Network Security Platform 8.1
IPS Administration Guide
389
15
Advanced botnet detection
How the Advanced Botnet Detection Framework works
0-day botnet detection
The Advanced Botnet Detection framework uses a probabilistic 0-day botnet detection approach,
targeted toward detection of 0-day bots. It consists of multiple heuristics identified during the
research and analysis of various bots. Heuristics cover a wide range of checks such as:
•
Anomalies in protocols being used for communication such as HTTP and SSL.
•
Response errors in protocols such as DNS, SMTP.
•
Suspicious behavior such as port scan and stealth scan.
•
Cloud based detection such as GTI File Reputation and IP Reputation.
The Advanced Botnet Detection framework monitors for such heuristics being exhibited by a particular
source IP address within a specified amount of time. This allows the framework to determine if the
source IP address has been compromised and is exhibiting bot behavior.
The following are some of the currently implemented heuristics:
•
SSL: Invalid SSL Flow Detected
•
SSL: Invalid SSL Flow Detected Due to Wrong Hello Record Type
•
SSL: Invalid SSL Flow Detected Due to wrong Record Version
•
SSL: Invalid SSL Flow Detected Due to Wrong Handshake Type
•
Heuristic DNS: Too Many Type A Query Response Errors Found
•
Heuristic DNS: Too Many Type MX Query Response Errors Found
•
DNS: Recursive Query To Root Servers Found
•
BOT Heuristic: Spam Bot Activity - Multiple Blacklist Responses from SMTP server
•
BOT Heuristic: Potential Bot Activity - Multiple Resets from SMTP receiver
•
Heuristic SMTP: Multiple Emails sent without Authentication
•
IRC: IRC Client Activity Detected
•
HTTP: Executable Files Found in Zip Files
•
HTTP: Password Protected Zip File Found
•
HTTP: Invalid Flow Detected
•
Bot: Potential Stealth Scanner Detected
•
GTI: Connection to High Risk External IP Detected
•
Malware: Potential Malicious File Transfer Detected by GTI File Reputation
(Artemis)
•
BOT: HTran Connection Bouncer Error Message Detected
0-day botnet detection examples
This section describes the detection of some popular and well known bots like Aurora, Kraken and
Pushdo with heuristics support. Specific traits and techniques implemented by these bots are detected.
390
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
How the Advanced Botnet Detection Framework works
15
Heuristics detected on Aurora and Pushdo bot traffic
The following are observed:
•
SSL Unix-Timestamp too old or too long into the future (SSL: Client Hello Invalid Unix
Timestamp)
•
Invalid SSL Flow (SSL: Invalid SSL Flow Detected)
The framework raises a medium confidence heuristic correlation bot alert, BOT: Potential Bot
Detected - Medium Confidence Heuristics Correlation.
Heuristics detected on Kraken bot traffic
The following are observed:
•
SMTP 5xx errors from servers (SMTP: Unexpected Server Rejection)
•
E-mails sent without authentication (BOT Heuristic: Potential Bot Activity - Multiple
Resets from SMTP receiver)
The framework raises a medium confidence heuristic correlation bot alerts, BOT: Potential Bot
Detected - Medium Confidence Heuristics Correlation.
The Advanced Botnet Detection framework which consists of all the above listed heuristics has proved
effective in detecting the following categories and traits exhibited by bots.
•
Spam bots (bots designed to assist in sending spam emails)
•
Domain Flux (bots that implement domain-generation algorithms to generate domains on the fly to
stay active and undetected)
•
IRC bots (bots that use IRC protocol to carry out malicious activities)
•
HTran (bots that use HTran a connection bouncer to redirect TCP traffic destined for one host to an
alternate host to hide the primary C&C server)
•
Suspicious scan activity (bots that usually scan to look for open ports and services on the system)
Known botnet detection
The Advanced Botnet Detection framework also uses a deterministic botnet detection approach,
targeted toward detection of known bots. As mentioned earlier, a bot lifecycle can be divided into
exploitation, infection and the attack/propagation phases. Each phase has a corresponding attack
signature to detect the phase. The framework monitors per source IP address the specified sequence
of these attack IDs within a specified time to trigger a correlated attack. This provides a precise bot
detection.
Consider the example of Kraken botnet. Kraken bot is known to have the following phases:
1
Connectivity test to mx.google.com.
2
Download Test: Front pages of popular news websites – www.nytimes.com, www.cbsnews.com,
www.cnn.com, and www.google.com.
3
Peer Lookup: DNS Queries for randomly generated URI based on dynamic DNS domains.
4
Peer Connect & Update: Connect to peer bot (UDP dport 447/TCP dport 80/TCP dport 443) and
download update.
5
Download Payload (Spam template, Spam Payload, MX server addresses and so on).
6
Send Spam.
McAfee Network Security Platform 8.1
IPS Administration Guide
391
15
Advanced botnet detection
Configure Advanced Botnet Detection from the admin domain
Phases 1 and 2 are not malicious by themselves. However, when correlated with phases, 3,4,5 and 6,
Kraken botnet can be detected effectively.
Known botnet detection example
Virut botnet detection
A machine infected with Virut bot can be detected by co-relating the component attacks. The
framework raises the alert, BOT: Virut Bot Activity Detected.
Configure Advanced Botnet Detection from the admin domain
To configure Advanced Botnet Detection from the admin domain:
Task
1
Select Devices | <Admin Domain name> | Global | Default Device Settings | IPS Devices | Advanced Botnet Detection.
Figure 15-1 Advanced Botnet Detection sub-tab
2
Select Low / Medium / High Sensitivity level from the drop-down list under Heuristic Detection field.
Heuristic detection correlates different bot activities and raises an alert when a specific condition is
met.
The sensitivity level determines the level of confidence the heuristic engine must have for the
analysis. For example, when a low sensitivity level is selected, the engine must have high
confidence that it has detected a bot before raising an alert.
Low sensitivity level is selected by default.
3
392
Click Save to save the configuration.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Configure Advanced Botnet Detection at the interface level
15
Configure Advanced Botnet Detection at the interface level
Task
1
In the Manager, select Devices | <Admin Domain> | Devices | <Device Name> | IPS Interfaces | <Interface Name> |
Protection Profile.
2
In the Protection Options section, click Advanced Botnet Detection.
The Advanced Botnet Detection page appears.
Figure 15-2 Advanced Botnet Detection dialog
3
Select Export Potential Botnet Events to NTBA for Further Analysis? under Advanced Botnet Detection to send the
botnet events to NTBA for further analysis.
Heuristic detection correlates different bot activities and raises an alert when a specific condition is
met. The sensitivity level determines the level of confidence the heuristic engine must have for the
analysis. For example, when a low sensitivity level (default) is selected, the engine must have high
confidence that it has detected a bot before raising an alert.
Events can be sent to NTBA even when the local detection is disabled.
4
If you want to inherit the configured URIs or blacklists from the admin domain, check Inherit Default
Settings for this Admin Domain? within the Heuristic Detection section. If not, proceed to step 5.
5
If you do not inherit the settings from the admin domain, select Low, Medium, or High sensitivity level
from the Sensitivity drop-down within the Heuristic Detection section.
The sensitivity level determines the level of confidence the heuristic engine must have for the
analysis.
Low sensitivity level is selected by default.
6
Click Save.
Figure 15-3 Sensitivity level
McAfee Network Security Platform 8.1
IPS Administration Guide
393
15
Advanced botnet detection
Bot Command and Control server activity detection
Bot Command and Control server activity detection
Detecting Bot Command and Control server activity is a key feature of the Advanced Botnet Detection.
Network Security Platform monitors networks for Bot attacks and protects the network by updating
the reputation of the newly identified Bot masters in the cloud, using McAfee GTI (GTI).
McAfee provides Bot intelligence that includes a Bot Command and Control database consisting of
known Command and Control URLs, server domain names and IP addresses. The Manager
communicates with the cloud to obtain the latest bot information available, in the form of Botnet
detectors on a periodic basis. This information is pulled by the Manager from the cloud.
The Network Security Manager devices query the cloud servers for updates to the Botnet Detectors
and download them to the Sensors.
How Botnet Detectors work
The Botnet Detectors are generated by McAfee. The Botnet Detectors contain information regarding
the IP addresses, domains, and URLs of the malicious Bot Command and Control servers, each of this
is categorized based on at least one or more relevant Botnet IDs. The Botnet Detectors also contain
the relevant ports and protocols that are monitored by Network Security Platform.
For enhanced botnet detection, download the latest Botnet Detectors or schedule automatic download
and deployment of the Botnet Detectors. The Manager downloads the Botnet Detectors and pushes
them to the Sensor. The Bot Command and Control server communications are detected by the Sensor
using the information in the Botnet Detectors. The Sensor inspects all traffic against the malicious IP
addresses and port numbers, domains and URLs in the Botnet Detectors and triggers alerts based on
them. The Sensor sends an alert to the Manager indicating the Botnet-ID detected along with the
Layer 7 information (if Layer 7 data collection is configured). The Manager uses the Botnet-ID
information in the alert to associate the information present in the Botnet Detector. This information
can be drilled down and viewed in the Dashboards and Threat Analyzer of the Manager.
Figure 15-4 Botnet detection
394
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Bot Command and Control server activity detection
15
Network Security Platform allows you to analyze bots using the Active Botnets dashboards. The
dashboards allow you to drill down into each piece of detected bot activity. The Active Botnets page
provides you with more details of the detected bot activity.
The Manager provides both automatic and manual import of the botnet detectors.
Manage Botnet Detectors
For Manager deployments that have access to the internet, the Manager automatically downloads
Botnet Detectors from the CDN server. For Manager deployments that do not have access to the
internet Botnet Detectors are to be downloaded manually.
Tasks
•
Download Botnet Detectors on page 395
•
Automatically updating IPS Signature Sets and Botnet Detectors on page 395
•
Manually import Botnet Detectors on page 396
Download Botnet Detectors
You can download Botnet Detectors and push it to the Sensor.
To download the latest available Botnet Detectors from the Manager:
Task
1
Select Manage | Updating | Download Botnet Detectors.
The latest and the preceding versions are available for you to download.
Figure 15-5 Download Botnet Detectors
2
Select the required version and click Download.
The latest Botnet Detectors are downloaded. You can view the active Botnet Detector version on
the Manager Dashboard page and on the Device Summary page.
The Botnet Detectors are pushed to the Sensor when you do a configuration update using Manage |
Deploy Configuration Changes. To perform a specific push of the Botnet Detectors to the Manager, update
the Botnet DAT under Devices | Deploy Configuration Changes.
Automatically updating IPS Signature Sets and Botnet Detectors
The Manager allows you to schedule the download of the IPS Signature set and Botnet Detectors.
Once configured, the scheduler downloads the IPS Signature set and Botnet Detectors from McAfee
update server to the Manager. For example, every one hour, the Manager checks the McAfee update
server and downloads the new file uploads.
The success/failure of the import process is indicated through fault notifications, emails and SNMP
traps.
Once the new IPS Signature set and Botnet Detectors are available on the Manager, they can be
scheduled to be deployed on your devices.
McAfee Network Security Platform 8.1
IPS Administration Guide
395
15
Advanced botnet detection
Bot Command and Control server activity detection
A proxy server is provided for all internet communications. You can manage the proxy server and
know the proxy details from the scheduler page.
Manually import Botnet Detectors
The Manager allows you to manually import the Botnet Detectors and the IPS signature set for your
devices from the file system if your Manager deployment has no access to the internet.
Task
1
Select Manage | Updating | Manual Import
The supported file format is .zip.
Figure 15-6 Manual file import
2
Browse to the file on your system and click Import.
On manual import, the Configuration Update has to be selected for all the Sensors having
Advanced Botnet detection enabled, so, along with the signature set update push, you need to do a
Botnet Data push.
The Manager audits the import process. The success or failure can be verified in the audit
messages.
Analyze Active Botnets
You can leverage the analysis technique provided by the Network Security Platform to perform an
in-depth analysis of the botnet activity in your network. The Manager provides you with a complete
view of the bot events and threats on your network for further analysis and actions thus providing a
comprehensive view of the threat landscape in your network. You can view the Top Active Botnets
dashboard. This dashboard is populated when bot activity is detected in your network. The dashboards
display the Botnet name and the Event Count. The Dashboard page security monitors are displayed as bar
charts.
Figure 15-7 Dashboard-Top Active Botnets
If you want to drill down further on a specific bot activity, click the bar, and you'll be redirected to the
Analysis | Active Botnets page, which displays additional details on that botnet. This page provides you
with the flexibility of filtering and sorting the information displayed based on your choices. In addition
to these filtering/sorting options, you can also view the alerts that match the filter criteria by opening
396
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Bot Command and Control server activity detection
15
the Threat Analyzer Alerts page directly from the Threats Explorer. You can view the botnet detections
specific to admin domains by selecting the required admin domain from the Domain drop-down list.
Summarized data for botnet detections, which includes data from the child domains, also can be
viewed. If you have integrated the Manager with McAfee products like ePolicy Orchestrator, Logon
Collector, or Vulnerability Manager, you can view the host name, operating system, open ports, known
vulnerabilities.
The following chart gives you the comprehensive analysis options provided by the Active Botnets page.
These tabs are explained in the subsequent sections.
Figure 15-8 Botnet analysis
You can analyze details of the active botnets such as, the botnet name, status of the Command and
Control Server communication, number of events and the details of the last event occurrence.
McAfee Network Security Platform 8.1
IPS Administration Guide
397
15
Advanced botnet detection
Bot Command and Control server activity detection
You can further analyze the details of all the zombies in the botnet. For each zombie you can view its
IP address, DNS name, operating system, user details, status of the Command and Control Server
communication, number of events and the details of the last event occurrence.
Figure 15-9 Analyze active botnets
Filters can be applied at the admin domain levels which provide bot data for the selected admin
domains. Data from the child domains are included in the data provided. The Include child domains
checkbox is selected by default. Deselect the checkbox to view data only for the selected admin
domain.
Figure 15-10 View data specific to admin domain
Botnet
This tab displays the following details of the selected botnet.
Field name
Description
About
Click to download the Detailed Botnet Report. The comprehensive botnet
report provides information such as the botnet description, symptoms of the
bot, bot prevention methods, bot removal tips etc.
Name
The name of the botnet family.
C&C communication About The status of the bot's communication with the Command and Control server,
whether blocked or unblocked.
Events
The number of bot events.
Last Event
The date and time of the occurrence of the last event.
Zombie for: 'Botnet'
This tab displays the following details of the selected zombie for a particular botnet.
398
Field name
Description
IP address
IP address of the attacker.
DNS name
DNS name of the endpoint to resolve the names to IP addresses.
OS
Operating system platform of the endpoint.
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Bot Command and Control server activity detection
Field name
Description
User
Operating system user name of the endpoint.
15
C&C communication The status of the bot's communication with the Command and Control server,
whether blocked or unblocked.
Events
The number of bot events.
Last Event
The date and time of the occurrence of the last event.
Comment
Additional comments on the botnet can be added.
Related events for: 'selected zombie'
This tab displays various events related to a specific zombie.
•
'Botnet' events
•
You can drill down further to analyze the details of every event reported.
Figure 15-11 Analyze botnet events
Field name
Description
Actions
Obtain the attacker forensics and the target forensics.
Time
The time the event occurred.
Attack
The name of the attack and the result of the attack on your network. You can
download the detailed botnet report by clicking in the About column.
Packet Capture
Download the packet log to analyze the affected data packets.
C&C Server
The Command and Control server details such as, the IP address of the server,
the country hosting the server and the port.
Direction
The direction of the traffic on which the attack is detected whether inbound or
outbound.
URL
The URL/domain associated with the event.
Bots
The associated active bots.
Activities
The activities associated with the botnet.
Overall Confidence The overall confidence level of the Sensor.
•
Endpoint Information
McAfee Network Security Platform 8.1
IPS Administration Guide
399
15
Advanced botnet detection
Bot Command and Control server activity detection
The Endpoint Information sub-tab shows the following details specific to the endpoint.
Figure 15-12 Analyze Endpoint Information
Item
Description
DNS Name
DNS name of the endpoint to resolve the names to IP addresses.
NetBIOS
NetBIOS name of the endpoint to access the endpoint machines.
Operating system
Operating system platform of the endpoint.
Device Type
Device type of the attacker/target.
MAC Address
MAC address of the endpoint.
Country
Country of the endpoint.
Domain/Workgroup
Domain or workgroup of the endpoint.
User
Operating system user name of the endpoint.
Data Source
Point product (ePO/MVM) from where information is retrieved.
McAfee Agent Check-In
Time
Check-in time of the McAfee Agent that communicates with the same ePO
server integrated with the admin domain.
L7 data
The corresponding L7 data is displayed.
Endpoint Type
Type of the endpoints:
• UNMANAGED (No Agent)— This indicates that there is no McAfee Agent
installed on the endpoint.
• UNMANAGED (MANAGED)— This indicates that the endpoint has a McAfee
Agent but there is no active communication channel between the Agent
and ePO server integrated with the admin domain.
Installed products
•
List of the installed products.
Threat Explorer
•
Explore as attacker IP— Explore the threats where the endpoint is the source IP address.
•
Explore as target IP— Explore the threats where the endpoint is the destination IP address.
For more information see the section Threat Explorer.
400
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Bot Command and Control server activity detection
•
15
Network Forensics— Click this tab to analyze the network behavior of the endpoint when NTBA is
configured.
Figure 15-13 Network Forensics page
You can filter your view by choosing the time and date of your choice.
Figure 15-14 Date and time options in Network Forensics page
The Show option helps you to select the Root Cause Analysis and Exposure Analysis options to analyze
the network behavior of the endpoint within a specific time.
Figure 15-15 Show option
For more information, see section Analyze Network Forensics.
•
View Alerts and PCAPs— Use this option to analyze and view the alerts. Using this option you can
navigate to the Threat Analyzer.
•
Analyze as attacker IP— View the alerts where the endpoint is the source IP address.
•
Analyze as target IP— View the alerts where the endpoint is the destination IP address.
McAfee Network Security Platform 8.1
IPS Administration Guide
401
15
Advanced botnet detection
Bot Command and Control server activity detection
•
Quarantine— Use this option to block all the traffic originating from the specified IP address seen
on the selected device for the selected time.
Figure 15-16 Quarantine Endpoint dialog
To block the traffic:
1
Select the specific device of the endpoint whose traffic originating from the IP address you
want to block.
2
Select the quarantine duration from the drop-down list.
The IP address of the endpoint is selected by default as the Attacker IP Address core attribute is
already selected.
402
McAfee Network Security Platform 8.1
IPS Administration Guide
Advanced botnet detection
Bot Command and Control server activity detection
•
15
Vulnerability Assessment
The Vulnerability Assessment sub-tab displays the following details. You can only view this section when
the Vulnerability Manager is configured.
Figure 15-17 Vulnerability Assessment sub-tab
Item
Description
General Activity Displays information such as the overall criticality of the endpoint, time of the last
scan and name of the scan engine.
•
Open Ports
Information about the open ports such as the description of the port, service
running on the port and the description.
Vulnerabilities
Vulnerability details such as the risk levels, the name and the CVE ID of the
vulnerability.
Endpoint Security Events
The Endpoint Security Events sub-tab displays the following details. You can only view this section when
McAfee ePolicy Orchestrator is configured.
Figure 15-18 Endpoint Security Events sub-tab
McAfee Network Security Platform 8.1
IPS Administration Guide
403
15
Advanced botnet detection
Bot Command and Control server activity detection
Item
Description
Latest Anti Virus
Events
The latest events including the date and time when the event was received by the
anti virus agent, the name of the threat that caused the event to appear, the type
of the threat that triggered the event, the action taken by the anti-virus agent on
the reported event, the path to the affected file that caused the event and the
method used to detect the anti-virus event.
Latest Host
Intrusion
Prevention
Events
The latest host intrusion prevention events including the date and time when the
event was received by the Host Intrusion Prevention agent, the name of the
signature that caused the event to appear, the severity level of the Host Intrusion
Prevention event, the user at the time the event was initiated, the application
process that triggered the event, the Source IP address for the event and the
reaction set to take place when the event is triggered.
For more information, see section McAfee Network Security Platform Integration Guide.
404
McAfee Network Security Platform 8.1
IPS Administration Guide
16
Denial-of-Service attacks
In a Denial-of-Service (DoS) attack, attackers take advantage of many hosts across the Internet,
which they had previously compromised, to launch a brute-force attack that starves the target of its
essential resources.
The objective of a DoS attack is to deprive organizations access to services or resources. If a website
is hit by a DoS attack, millions of users are denied access to the website. As such, DoS attacks do not
aim at intruding a network or information theft. By preventing authorized and legitimate access, DoS
attacks cause aggravation and cost to the target customer. Distributed Denial-of-Service (DDoS) uses
multiple compromised systems to launch an attack. This amplifies the effect of an attack.
Some of the DoS attacks are hard to defend because DoS packets appear to be normal packets. Most
DoS attacks use spoofing and flooding techniques to impact network infrastructure.
The degraded service and lost business from a DoS attack leads to staggering costs both during and
after an attack. For an e-commerce site like eBay or Buy.com, one day of disruption due to a DoS
attack can result in huge revenue loss. The SQL Slammer worm, a DoS attack that made
mission-critical Microsoft® SQL servers inaccessible, cost corporations billions of dollars worldwide.
Beyond the immediate costs, the lasting effects of a successful DoS attack include lost customers, loss
of faith in the service’s dependability, and damage to the corporate brand.
Contents
What is a Denial-of-Service attack?
What is a Distributed Denial-of-Service attack?
Evolution of Denial-of-Service attacks
How a Denial-of-Service attack works
DoS attacks defended against by Network Security Platform
DoS attack detection mechanism
Layer 7 DoS protection for web servers
Manage DoS attack definitions for an interface and a subinterface
Denial-of-Service profile advanced scanning
DoS attack prevention methods
Managing DoS-related actions using command line interface
Connection Limiting policies
What is a Denial-of-Service attack?
A DoS attack is a malicious attempt to render a service, system, or network unusable by its legitimate
users. Unlike most other hacks, a DoS does not require the attacker to gain access or entry into the
targeted server. The primary goal of a DoS attack is instead to deny legitimate users access to the
service provided by that server.
McAfee Network Security Platform 8.1
IPS Administration Guide
405
16
Denial-of-Service attacks
What is a Distributed Denial-of-Service attack?
Attackers achieve their DoS objective by flooding the target until it crashes, becomes unreachable
from the outside network, or can no longer handle legitimate traffic. The actual volume of the attack
traffic involved depends on the type of attack traffic payload used. With crafted payload such as
malformed IP fragments, several such packets might be sufficient to crash a vulnerable TCP/IP stack;
on the other hand, it might take a very large volume of perfectly conforming IP fragments to
overwhelm the defragmentation processing in the same TCP/IP stack. Sophisticated attackers might
choose to use a mixture of normal and malformed payloads for a DoS attack. DoS attacks can vary in
impact from consuming the bandwidth of an entire network, to preventing service use of a single
targeted host, or crashing of a single service on the target host.
Most DoS attacks are flood attacks; that is, attacks aimed at flooding a network with TCP connection
packets that are normally legitimate, but consume network bandwidth when sent in heavy volume.
The headers of malicious packets are typically forged, or spoofed, to fool the victim into accepting the
packets as if they are originating from a trusted source.
What is a Distributed Denial-of-Service attack?
A Distributed Denial-of-Service (DDoS) is a type of DoS attack that is launched from compromised
hosts distributed within or across networks. A DDoS attack is coordinated across many systems, all
controlled by a single attacker known as a master. Prior to the attack, the master compromises a large
number of hosts, typically without their owners’ knowledge, and installs software that will later enable
the coordinated attack. These compromised hosts, called zombies are then used to perform the actual
attack. Zombies are also called daemons, agents, slaves, or bots. When the master is ready to launch
the attack, every available zombie is contacted and instructed to attack a single victim. The master is
not a part of the attack, thus tracing the true origin of a DDoS attack is very difficult. As with a DoS
attack, packets sent from each zombie might be spoofed to fool the victim into accepting data from
the trusted source. DDoS allows the attackers to utilize the network to multiplex low-volume sources
into a high-volume stream to overwhelm the targets. Through the master-zombie communication, the
real attackers can potentially hide their identities behind the zombies.
Evolution of Denial-of-Service attacks
In the recent past, DoS attacks were performed by individuals, using the physical resources of one or
a handful of computers. This was primarily because of a lack of technical know-how to perpetrate
large scale attacks. Gradually, easy-to-use utility programs evolved which made performing DoS
attacks easier. This lead to an increase in the occurrences of DoS attacks. The surge in DoS attacks
was especially notable with many web-based companies being targeted. These included major
websites such as Amazon, Ebay!, and Microsoft.
DoS attacks evolved further with the usage of tools, which perpetrate attacks generated by malware.
Once installed, the malware would direct the infected machine to attack specific targets. If multiple
infected computers targeted the victim simultaneously, the effects of the attack were greatly
amplified.
The next evolution of DoS saw the attackers develop botnets, which are a centrally managed network
of compromised computers. This followed the upsurge in DDoS attacks. In a DDoS attack, an attacker
uses multiple machines to launch an attack. The internet saw the invention or refinement of
techniques to bring computers under the attackers' control and to produce powerful attacks. DoS
attacks are the most significant threat in the online world today, especially for businesses which
depend on web-based transactions.
406
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
How a Denial-of-Service attack works
16
How a Denial-of-Service attack works
In most DoS attacks, the legitimate users are denied access to an online resource, a website, or a
server. This is achieved by exhausting the physical resources of the victim or by disrupting network
connections to it. There are also some specific DoS attacks which exploit a flaw in the target. These
are known as vulnerability attacks. However, the result is the same — disruption of the network
services. The two most common methods of perpetrating a DoS attack is targeting physical resources
and network connections.
Targeting physical resources
Targeting physical resources of a victim is often an effective tactic because it is a violation of how the
internet works. The virtual world of the internet is a web of interconnected physical resources, such
as, bandwidth, processors, memory and so on. These resources are limited. For example, at any given
time, a website processes a number of requests. Once this number is achieved, all the current
requests are processed before handling new ones. If a DoS attacker continues to flood the website
with requests, new requests are prevented from being fulfilled. The legitimate user requests are also
denied access. Thus creating a DoS attack.
Targeting network connections
The Internet depends on network connection, such as, connections established between a website and
a user's computer. The number of connections that can be established with a website are limited.
Additionally, the connections should conform to certain protocols. An attacker disrupts these
connections by using invalid or an exhaustive number of connection requests to flood the victim. This
results in a DoS attack.
Attacked systems see an upsurge in network traffic. If the system does not crash from the attacks, its
network capacity is exhausted. Some attacks generate traffic at the rate of several gigabits per
second, which far exceeds the capacity of most Internet sites. The increase often results in the
Internet service being significantly slowed or completely disconnected. Attempts to form new
connections, or reconnect, might not be processed at all.
DoS attacks defended against by Network Security Platform
In McAfee® Network Security Platform, DoS attacks are classified into two main categories based on
their design.
Volume-based attacks are largely bandwidth attacks. When a DoS attack is launched, it is detected as
a significant change in the statistical composition of the network traffic. For example, a typical network
might consist of 70 percent TCP and a 30 percent mix of UDP and ICMP. A significant and unusual
variation in the statistical mix is a signal of a new attack.
In a flood attack, server or network resources are exhausted by a flood of packets. Since a single site
perpetrating a flood attack can be identified and isolated easily, a more sophisticated approach, a
DDoS attack, is used for many flood attacks.
Attacks, such as SYN floods, use packets to exhaust critical server resources to prevent legitimate
clients from connecting to the server. A DDoS attack utilizes a number of machines in a coordinated
manner. These machines, known as zombies, are machines that have been compromised and are
under the attackers’ control. By deploying zombies, hackers can stage large coordinated attacks. As
attacks originate from a large number of PCs spread across a wide network, it is extremely difficult to
separate legitimate traffic from attack traffic.
McAfee Network Security Platform 8.1
IPS Administration Guide
407
16
Denial-of-Service attacks
DoS attacks defended against by Network Security Platform
The sophistication required and barrier to launch these DDoS attacks has been greatly reduced
through the availability of packaged tools that are freely available on the Internet. Some examples of
these packaged tools are Tribe Flood Network and Stacheldraht.
Volume-based Denial-of-Service attacks
Volume-based DoS attacks are statistical anomalies in the traffic monitored by a McAfee® Network
Security Sensor. In other words, with insight into the normal distribution and volume of traffic, the
Sensor looks for significant changes in these levels, which can indicate malicious behavior.
TCP SYN attack
A TCP SYN attack takes place when the attacker sends a large volume of TCP SYN packets using
spoofed IP addresses to the target host. This fills up data structures on servers and creates a DOS
condition.
Consider the following example. Two hosts establish a TCP connection using the three-way handshake
— A sends a SYN segment to B; B responds with a SYN/ACK segment; A responds with an ACK
segment. A SYN flood attack occurs when a site is inundated with SYN segments containing spoofed IP
source addresses such as nonexistent or unreachable addresses. B responds with SYN/ACK segments
to these addresses and then waits for responding ACK segments. Because the SYN/ACK segments are
sent to nonexistent or unreachable IP addresses, they never elicit responses and eventually time out.
When a host is flooded with incomplete TCP connections, a DoS condition is created.
Once this buffer is full, the host can no longer process new TCP connection requests, even the
legitimate ones. The attack disables the victim and its normal operations.
Figure 16-1 A TCP SYN flood
408
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attacks defended against by Network Security Platform
16
See also
SYN cookie on page 456
Statistical anomaly on page 454
TCP full-connect attack
A TCP full-connect attack is an attack that has a valid source IP address and goes though the full TCP
hand-shake process. The attacker uses real PCs with real IP addresses to generate a TCP full-connect
attack. This is typically done using botnets. Sending TCP full-connect attacks from several botnets ties
down server resources and creates a DoS condition. TCP full-connect usually is a DDoS attack
launched from botnets in distributed systems.
A bot is defined as malicious software running on a compromised system that is designed to
participate in a centrally managed network of compromised computers known as a botnet. Single
botnets have been known to consist of over a million compromised computers, and are arguably the
most significant threats to the global Internet today.
Multiple systems access a single Internet or service in a way that appears legitimate. This makes the
detection of botnet-based DoS attacks difficult as it is hard to distinguish legitimate requests from
those coming from a botnet. In the past, social networking site, Twitter is known to have experienced
a DoS attack from a botnet.
See also
Connection limiting with McAfee GTI integration enabled on page 458
Statistical anomaly on page 454
TCP ACK/FIN attack
A TCP ACK/FIN attack takes place when the attacker sends a large volume of TCP ACK/FIN packets
intentionally to the target host. This consumes bandwidth and creates a DoS condition.
See also
Stateful TCP engine on page 456
Statistical anomaly on page 454
TCP RST attack
A TCP RST attack takes place when the attacker sends a large volume of malicious, mimicked TCP RST
packets aimed to prematurely terminate active TCP sessions.
In TCP RST attacks, the network is constantly monitored for TCP connection requests sent to the
victim. As soon as such a request is found, the attacker sends a spoofed TCP reset packet to the
victim and obliges it to terminate the TCP connection.
Consider the following example. Computer A crashes while a TCP connection is in progress. Ccomputer
B, on the other end, interacting with computer A continues to send TCP packets since it does not know
computer A has crashed. When computer A restarts, it receives packets from the pre-crash
connection. Computer A has no context for these packets and sends a TCP reset to computer B. This
reset lets computer B know that the connection is no longer working. The user on computer B tries
another connection. However, a third computer or computers (DoS attackers) monitoring the TCP
packets on the connection, might send premature forged or mimicked TCP reset packets to one or
both endpoints to terminate active TCP connections.
This attack consumes system resources that receive, check, and discard the packets, thus causing a
DoS condition.
McAfee Network Security Platform 8.1
IPS Administration Guide
409
16
Denial-of-Service attacks
DoS attacks defended against by Network Security Platform
DNS flood attack
Sending a flood of DNS requests to a server constitutes a DNS flood attack. Since DNS uses UDP, no
hand-shake process is involved. A flood of DNS requests can tie down the resources of a DNS
infrastructure and create a DoS condition.
DNS servers like other Internet resources are prone to DoS attacks. DNS uses UDP queries for name
resolution and so a full circuit is never established (as contrasted with TCP) DoS attacks are difficult to
trace and block. DNS flood works by sending a flood of rapid DNS requests from multiple machines,
thereby giving the server more traffic than it can handle resulting in slower response time for
legitimate requests.
Consider the following example where a DNS flood is run from one machine and the DNS server
queried from another machine. The attacking machine sends different types of DNS packets, each with
a different spoofed source port to the target. To assess the impact of this attack on the victim's
performance, the attacker first clears his local cache from another machine and then queries the
target name server. Clearing the local cache ensures the resolver gets the information from the server
and not locally. The attacker then stops the attack and queries the target name server once again
from another machine, after clearing the cache. The queries during the attack and after the attack
prove a significant performance impact on the victim server. If this attack was multiplied from a
number of machines, the impact would be even greater.
See also
DNS protect on page 456
Connection limiting with McAfee GTI integration enabled on page 458
Statistical anomaly on page 454
UDP flood attack
Sending a flood of UDP attacks to a targeted system constitutes a UDP flood attack. When
communication is established between two UDP services, an UDP flood attack is initiated by sending a
large number of UDP packets to random ports of the targeted system. The targeted system is forced
into sending many Destination unreachable UDP packets, thus consuming its resources and leading to
DoS. As UDP does not require any connection setup procedure to transfer data, anyone with network
connectivity can launch an attack; no account access is needed.
410
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attacks defended against by Network Security Platform
16
Another example of UDP flood is connecting a host's chargen service to the echo service on the same
or another machine. All affected machines might be effectively taken out of service because of the
excessively high number of packets produced. In addition, if two or more hosts are so engaged, the
intervening network might also become congested and deny service to all hosts whose traffic traverse
that network.
Figure 16-2 UDP flood
See also
Rate Limiting on page 458
Connection limiting with McAfee GTI integration enabled on page 458
Statistical anomaly on page 454
ICMP flood attack
This attack involves flooding the network with ICMP echo request or reply packets. A flood of echo
requests to a target system makes the system busy responding to the requests. If there is a flood of
reply packets, it is very likely that the remote attacker has forged an IP address from within your
network and is sending ICMP echo request packets to another network. That network replies to the
address in the requests, thus starting a request/reply flood between the two networks.
In such an attack, the attackers send large numbers of IP packets with the source address faked to
appear to be the address of the victim. The network's bandwidth is consumed, preventing legitimate
packets from getting through to their destination.
McAfee Network Security Platform 8.1
IPS Administration Guide
411
16
Denial-of-Service attacks
DoS attacks defended against by Network Security Platform
A variation of an ICMP flood is also known as the smurf attack, named after a program capable of
generating this attack. In such an attack, an ICMP echo request is sent to a broadcast network
address, acting as an amplifying agent. The source address of the victim is spoofed. The result is a
flood of replies from that network which, takes the victim's network down.
Figure 16-3 ICMP flood attack
See also
Rate Limiting on page 458
Connection limiting with McAfee GTI integration enabled on page 458
Statistical anomaly on page 454
Non TCP/UDP/ICMP flood attack
This involves flooding the network with packets other than TCP, UDP, or ICMP. Packets involved in this
attack might include IPSec and malformed IP packets (such as IP with bad checksums and
inconsistent length).
See also
Statistical anomaly on page 454
Application level flood
Attackers often use expensive queries to slow down servers causing resource exhaustion and denial of
service. Traditional denial of service detection techniques might not identify the attack because the
volume of queries can be too small.
See also
Custom Reconnaissance Attack Definition on page 459
412
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
Vulnerability-based DoS attacks
Unlike volume-based DoS attacks, vulnerability-based or exploit-based DoS attacks are generally
single requests that can result in a DoS condition. Vulnerability-based DoS attacks exploit
vulnerabilities in the network and its systems. The following table describes some well-known
examples of vulnerability-based DoS.
Attack name
Description
TearDrop attack
This involves fragmented ICMP packets with overlaps among the fragments.
Such fragments cause certain implementations of the IP stack to crash or go into
an infinite loop, thus leading to a DoS condition.
Ping of Death
attack
This involves sending packets that exceed the maximum authorized size (65,536
bytes) to a system with a vulnerable TCP/IP stack, causing it to crash.
Land attack
This involves using IP-address spoofing with the same IP address and port
number in the source and destination fields, causing vulnerable systems to
become unstable.
See also
Exploit-based DoS attack detection on page 429
Distributed Denial-of-Service attack tools
DDoS attacks can be launched by using tools that are built to generate DDoS attacks.
There are many DDoS attack tools. Some well-known tools are listed below:
•
Trinoo — is an attack tool that installs agent programs on compromised hosts and uses the agents
through a master program to attack one Trinoo, or more target hosts by flooding them with UDP
packets. Communication between the master and agents is password protected.
•
Tribal Flood Network (TFN) — TFN uses an attack approach similar to Trinoo, can generate
multiple attacks, and use spoofed IP addresses. ICMP echo request flood, TCP SYN flood, and UDP
flood are some of the attacks that can be launched by TFN.
•
TFN2K — TFN2K is an advanced version of TFN with features that makes it more difficult to detect.
TFN2K uses multiple protocols including UDP, TCP, and ICMP.
•
Stacheldraht — Stacheldraht, which means barbed wire in German, has features that include
those of Trinoo and TFN. Stacheldraht has features like encrypted communication between agents
and the master program.
•
Shaft — Shaft is a tool similar to Trinoo that can launch packet-flooding attacks.
•
Trinity — Trinity is a flood attack tool that uses chat programs such as Internet Relay Chat (IRC).
•
MStream — MStream is a tool based on stream.c attack in which access to the handler is
password protected.
DoS attack detection mechanism
McAfee® Network Security Platform provides an integrated hardware and software solution, which
delivers comprehensive protection from known, first strike (unknown), DoS, and DDoS attacks from
several hundred Mbps to multi-gigabit speeds.
The Network Security Platform architecture employs a combination of threshold-based, self-learning,
profile-based detection techniques to detect DoS and DDoS attacks.
McAfee Network Security Platform 8.1
IPS Administration Guide
413
16
Denial-of-Service attacks
DoS attack detection mechanism
With threshold-based detection, you can configure data traffic limits to ensure your servers will not
become unavailable due to overload. These thresholds are selected based on coverage of different
DDoS attacks and on the availability of statistics that will help the users to configure them. Meanwhile,
self-learning methodologies enable Network Security Platform to study the patterns of network usage
and traffic over time; thus understanding the wide variety of lawful, though unusual, usage patterns
that might occur during legitimate network operations. The learning algorithm takes into account
sudden bursts that is common in all network traffic, and differentiates it from the real onset of DDoS
traffic. In addition to learning the intensity behavior, it also learns the correlational behavior of
different types of packets, which reliably captures TCP/IP protocol behavior, route configuration, and
so on. Highly accurate DoS detection techniques are essential because popular websites and networks
do experience legitimate and sometimes unexpected traffic surges during external events, or for a
particularly compelling new program, service, or application.
The combination of these two techniques yields the highest accuracy of detection for the full spectrum
of DoS and DDoS attacks, when hundreds or even thousands of hosts are co-opted by a malicious
programmer to strike against a single victim.
Once DoS/DDoS attacks have been detected, Network Security Platform offers methods to block
various types of DoS Attacks.
Volume-based DoS attack detection
Network Security Platform detects volume-based DoS attacks through threshold-based and statistical
anomaly-based (learning-based) methods. Often a combination of these two methods is used.
Threshold-based mode
In the threshold mode, the Sensor monitors the network traffic for packet floods, such as too many IP
fragments, transmitting through from a source to a destination as detected within a Sensor interface
or subinterface. When configuring the DoS policy or customizing at the interface or subinterface level,
you must specify the count and interval rate in seconds, for the threshold attacks you want to detect.
The Sensor sends an alert, if configured to do so in the DoS policy, when the traffic exceeds the
customized thresholds for an enabled attack. You can also enable a notification for an attack if it
warrants special attention. For threshold-based attacks, a Sensor monitors both inbound and
outbound traffic.
This method requires that you to fully understand your typical traffic pattern to pick good threshold
values; otherwise it can produce false alarms due to traffic fluctuations, such as flash crowds — for
example, everyone logging on the network at 9 a.m.— or other legitimate increased traffic.
Although default values are provided for thresholds and intervals, you must configure the actual
thresholds and intervals for each DoS threshold mode attack you want to detect. Customization of DoS
thresholds works best after researching the current levels to be defended for each DoS threshold. This
helps you to determine exactly what counts and intervals are best for protecting your network.
The threshold method involves specifying the count and interval thresholds while configuring a DoS
policy in the Manager. When the threshold is crossed, the DoS attack is detected.
Threshold value and interval can be customized in the Manager for threshold attacks, such as:
414
•
Inbound Link Utilization (Bytes/Sec) Too
High
•
Too Many Inbound Rejected TCP Packets
•
Too Many Inbound ICMP Packets
•
Too Many Inbound TCP Connections
•
Too Many Inbound IP Fragments
•
Too Many Inbound TCP SYNs
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
•
Too Many Inbound Large ICMP packets
•
Too Many Inbound Large UDP packets
•
16
Too Many Inbound UDP Packets
Learning-based (statistical anomaly-based) mode
A new Sensor runs for its first 48 hours in learning mode. After 48 hours, the Sensor automatically
changes to detection mode, having established a baseline of the normal traffic pattern for the
network, or a long-term profile. The assumption is that there are no DoS attacks during those first 48
hours.
After moving to detection mode, the Sensor continues to gather statistical data and update its
long-term profile. In this way, the long-term profile evolves with the network. The Sensor also builds
short time profiles with a time window of a few minutes.
Learning mode profiles can be managed in the DoS Data Management page of the Manager. DoS profile
learning can be rebuilt (re-learned) or reloaded at this level. To access the DoS Data Management page:
1
Click the Devices tab.
4
Select the device from the Device drop-down
list.
2
Select the domain from the Domain
drop-down list.
5
Select Policy | Denial of Service | Data Management.
3
In the left pane, click the Devices tab.
Subinterfaces and individual CIDR hosts within a VLAN tag or CIDR block can be created and protected
against DoS attacks with specific learning-mode settings. This is useful in preventing a server in your
DMZ or other location from being shutdown by a DoS attack. A separate profile is created for each
resource.
The statistical method uses statistical data gathered over a time window to create normal short-term
and long-term profiles. DoS attacks are detected when there are anomalies between the traffic pattern
in normal profiles and network traffic. Statistical anomalies in traffic are monitored by the Sensor with
reference to learned data on normal traffic.
The Sensor uses the following checks and counter checks to ensure accuracy of detection:
•
Counter profile contamination
•
Source IP address classification
If there is a change in the routing scheme, McAfee recommends instructing the Sensor to relearn the
network so that it can create a new baseline.
Countering profile contamination
The goal behind the long-term profile is to define normal traffic levels. The Sensor can identify
anomalous spikes in traffic with reference to the defined normal levels. The Sensor also uses the
gathered statistical data to calculate short-term profiles, that is statistical data averaged over a time
window of a few minutes.
McAfee Network Security Platform 8.1
IPS Administration Guide
415
16
Denial-of-Service attacks
DoS attack detection mechanism
If a short-term profile, which includes DoS attack data, is used to update the long-term profile, it
contaminates the long-term profile. Network Security Platform uses the following counter measures to
help prevent contamination:
•
When in detection mode, the Sensor temporarily ceases updating the long-term profile if too many
statistical anomalies are seen over a short period.
•
The Sensor uses percentile measure. A few large spikes in the short-term data will probably upset
a simple average, but are less likely to affect a percentile measure. For example, imagine a group
of four students taking an exam with percentile measure ranges of 0-29, 30-49, 50-69 and 70-100
for judging the effectiveness of the exam. Let us say three of the students receive grades of 95
percent, 93 percent, and 92 percent and the fourth receives a grade of 0 percent. The average
score is only 70 percent but three of the four students are still in the 70-100 range. The teacher
can therefore use the percentile ranges as a valid measure for judging the effectiveness of the
exam.
Source IP address classification
The Sensor builds unique source IP address profiles; one profile for each tracked packet type in each
direction.
See also
Statistical anomaly on page 454
How the DoS attack detection mechanism works
The Sensor is deployed inline in the host network; having established the baseline of the normal traffic
pattern for the network in the first 48 hours of deployment (learning mode), and built a long-term
profile for the statistical data on the SYN segments in the TCP connection. Consider that the Sensor is
in the detection mode. It continues to gather statistical data and update its long-term profile. The
learning mode uses statistical data gathered over a time window to create normal short-term and
long-term profiles.
416
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
Consider the following example of a TCP SYN flood attack.
Figure 16-4 TCP SYN flood attack
•
There is a flood of TCP SYN packets using spoofed IP addresses to the target host.
•
The Sensor detects a high volume of inbound TCP SYN packets. This upsurge in the packets is
regarded as an anomaly between the traffic pattern in normal profiles and the actual network
traffic. The Sensor monitors statistical anomalies in traffic with reference to learned data (DoS
profiles) on normal traffic. Refer to section, Statistical anomaly. The following is a sample DoS
profile. Bin 2 indicates a lower percentage of long-term traffic when compared to the short term,
and hence traffic is blocked.
0: 0.0.0.0/6 AS=1.563% LT=49.969% ST=100.00% stR=1.000
1: 128.0.0.0/2 AS=25.000% LT=0.021% ST=0.00% stR=0.000
*2: 64.0.0.0/2 AS=25.000% LT=1.615% ST=100.00% ltR=2357.098 stR=148966.400
3: 192.0.0.0/2 AS=25.000% LT=0.021% ST=0.00% stR=0.000
4: 32.0.0.0/3 AS=12.500% LT=0.000% ST=0.00% stR=0.000
5: 16.0.0.0/4 AS=6.250% LT=0.000% ST=0.00% stR=0.000
6: 8.0.0.0/5 AS=3.125% LT=0.000% ST=0.00% stR=0.000
7: 4.0.0.0/6 AS=0.000% LT=11.752% ST=0.00% ltR=16885.654 stR=0.000
McAfee Network Security Platform 8.1
IPS Administration Guide
417
16
Denial-of-Service attacks
DoS attack detection mechanism
•
Based on the configured DoS policy settings, alerts are raised in the Threat Analyzer. The learning
mode can be customized on the Manager for inbound, outbound, or bidirectional traffic. The
severity of the attack and Sensor response is also configurable. Refer to section,Configure the
Learning mode.
•
The alerts in the Threat Analyzer display the SYN packet rate data relating to the violated learning
mode measure, the violated measure's packet rate for the last minute when the alert was raised,
and the ranges of IP addresses, both source and destination, that were involved in the DoS attack.
Refer to section, View Denial-of-Service alerts in the Threat Analyzer.
•
The Sensor blocks any further inbound attack packets. The blocking of packets can be enabled
while configuring the learning mode or from the Threat analyzer once an alert is raised.
•
Additionally, thresholds can also be set to monitor the number of packets per second.
In the threshold mode, the Sensor monitors the network traffic for packet floods, transmitting
through from a source to a destination as detected within a Sensor interface or subinterface. When
configuring the DoS policy or customizing at the interface or subinterface level, the count and
interval (rate in seconds) for the threshold attacks to be detected.
Combining threshold and learning methods greatly improves reliability of detection.
DoS policy applies to inbound, outbound, and bidirectional traffic. Inbound traffic is that traffic
received on the port designated as outside (that is, originating from outside the network) in inline or
tap mode. Typically, inbound traffic is destined to the protected network, such as an enterprise
intranet.
Outbound traffic is that traffic sent by a system in your intranet, and is on the port designated as
inside (that is, originating from inside the network) in inline or tap mode.
When McAfee® Global Threat Intelligence™ is enabled, IP Reputation is applicable for every connection
but it is used differently for inbound and outbound connections:
•
For outbound connections – When McAfee GTI reports destination host as malicious, then a "GTI:
High Risk External IP Detected" alert is raised. You can configure the Sensor to block the
corresponding traffic. The external malicious host reputation is then cached and all connections to
that host are blocked.
•
For inbound connection – When McAfee GTI is enabled and Connection Limiting rules are
configured, you can block the malicious traffic received on the inbound connections. For example,
you can deploy a Sensor in front of a web server, and enable McAfee GTI along with Connection
Limiting policies and Advanced Malware policies to limit access to the server and prevent DoS
attacks.
Configure the threshold mode
The threshold method provides administrators with a way to trigger alerts if a preconfigured traffic
volume threshold is exceeded.
The key to successfully using thresholds is to have an understanding of the normal traffic levels on the
network. In most cases, an external device such as a sniffer is used to baseline the network, and the
initial levels are set according to that data. Once a baseline has been established, the administrator
can enable the relevant threshold for an attack and configure each with values that make sense for a
particular network.
Follow the tasks below to set threshold values for DoS attack definitions using Default IPS Attack Settings.
Note that the changes that you make through Default IPS Attack Settings feature affects the corresponding
attack definitions in all the IPS policies.
418
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
Task
1
Click the Policy tab.
2
Select the root admin domain from the Domain drop-down list.
3
Select Intrusion Prevention | Advanced | Default IPS Attack Settings.
The Default IPS Attack Settings page is displayed.
Figure 16-5 Threshold mode area
4
Click DoS Attacks and then click Inbound or Outbound as required.
Bidirectional is not relevant for threshold.
5
Click Threshold Mode.
6
Locate the required attack definition and click View / Edit.
You can also select more than one attack definition and click Bulk Edit. For the sake of explanation,
assume that you are modifying a single attack.
McAfee Network Security Platform 8.1
IPS Administration Guide
419
16
Denial-of-Service attacks
DoS attack detection mechanism
7
Set the attack threshold.
For example, select Customize Threshold Valueand Customize Threshold Interval checkboxes, and type 1000
and 1 respectively as values for these selections in the Edit Threshold Attack Details page for Inbound Link
Utilization (Bytes/Sec) Too High attack. Such a setting will enable an alert to be sent if a Sensor sees 1000
or more Inbound Link Utilization within a 1-second interval.
Figure 16-6 Edit Threshold Attack Details window
The Threshold method can be configured only to send alerts; traffic meeting or exceeding the
pre-defined thresholds cannot be blocked.
The Threshold method is used mostly for troubleshooting. The administrator might want to be
notified if bandwidth utilization goes above a pre-defined limit.
In contrast to the threshold method, the learning-based method automatically establishes a
baseline and if configured, can alert or block if that baseline is exceeded in such a way that it
constitutes an attack.
8
After you complete the customizing the attacks, click Save and deploy the configuration changes to
the corresponding Sensors.
Configure the learning mode
You can customize the learning mode for DoS attack definitions using Default IPS Attack Settings. Note that
the changes that you make through Default IPS Attack Settings feature affects the corresponding attack
definitions in all the IPS policies. You can also edit DoS attack definitions per IPS policy.
Task
1
Click the Policy tab.
2
Select the root admin domain from the Domain drop-down list.
3
Select Intrusion Prevention | Advanced | Default IPS Attack Settings.
The Default IPS Attack Settings page is displayed.
420
4
Click DoS Attacks and then click Inbound, Outbound, or Bidirectional as required.
5
Click Learning Mode.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
6
16
Locate the required attack definition and click View / Edit.
You can also select more than one attack definition and click Bulk Edit. For the sake of explanation,
assume that you are modifying a single attack.
Network Security Platform provides enforcement of DoS traffic profiling by direction of the flow:
Inbound, Outbound, or Bidirectional. You must enable attacks for each direction separately.
Figure 16-7 Learning mode area
Table 16-1 Option definitions
Option
Definition
Attack Name
Full name of the attack.
Severity
Potential impact of the attack.
Attack Description
Click to open the full attack description.
Annotate Description
Click to add your annotations for an attack in the attack encyclopedia.
Benign Trigger Probability Displays a value that indicates the chance that detection for the attack will
trigger an alert falsely.
7
Select the Customize Severity checkbox and select a different severity level from the Customize Severity
drop-down list, if you want the attack to be of a higher or lesser priority.
McAfee Network Security Platform 8.1
IPS Administration Guide
421
16
Denial-of-Service attacks
DoS attack detection mechanism
8
In the Sensor Response area, select Customize and Enable Alert checkboxes to activate the alert for this
attack.
Figure 16-8 Edit Learning Attack Details window
To customize notifications, first select Customize next to each response under Notifications and select the
Email, Pager, Script, SNMP, Auto. Ack. and Syslog checkboxes as required.
9
Select the Blocking (Drop DoS attack packets of this attack type when detected)checkbox if you want to drop
offending DoS packets when they are detected.
You must set this for each learning mode attack you want dealt with in this manner. This only
applies to a Sensor deployed in inline mode.
10 After you complete the customizing the attacks, click Save and deploy the configuration changes to
the corresponding Sensors.
Alerts for DoS attacks
DoS related alerts are raised when a Sensor detects volume-based DoS attacks, vulnerability based
DoS attacks, and attacks by DDoS attack tools. Network Security Platform uses attack signatures to
detect communication between many known DDoS attack tools, and also to detect vulnerability-based
attacks. Alerts are raised in the Threat Analyzer when such attacks are detected.
In the case of volume-based attacks, Sensor looks for statistical anomalies in short-term and
long-term profiles. The Sensor compares the short-term profile against the long-term profile. If there
is a significant difference in the traffic levels, an alert is generated, and the Sensor blocks traffic with
statistical anomalies if configured to do so.
422
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
The Sensor raises an alert when it detects one of two varieties of statistical anomalies:
•
Categorical or imbalance anomalies
•
Volume anomalies
Statistical anomalies are the result of an attack when the long-term profiles accurately reflect the
normal traffic for a given network. However variations in network traffic, due interventions such as
changes in the routing scheme, can cause anomalies. In such cases you must rebuild the profile from
scratch using the Rebuild the DoS Profiles (start the learning process from scratch) option in the DoS Data Management
page.
Follow these steps to go to the DoS Data Management page:
1
Click the Devices tab.
4
Select the device from the Device drop-down
list.
2
Select the domain from the Domain
drop-down list.
5
Select Policy | Denial of Service | Data Management.
3
In the left pane, click the Devices tab.
Categorical (or imbalance) anomalies
Certain types of packets are intrinsically related. Without ICMP echo reply, for example, ICMP echo
request would be of little use. Similarly, without FIN and RST, you would be able to begin a TCP
connection, but not end it.
Network Security Platform detects two types of categorical anomalies:
•
ICMP echo anomalies (echo request and echo reply)
•
TCP control segment anomalies (SYN, SYN ACK, FIN, and RST)
Network Security Platform records the distribution of these types of packets in its long-term profile. A
significant change in the distribution of these packet types in the short term is a reliable indication of
malicious behavior.
For example, Network A might have 50 echo replies for every 50 echo requests, whereas Network B
might have only 40 replies for 60 requests. In this case, the distribution would be 50 percent / 50
percent and 40 percent / 60 percent, respectively. In practice, distribution differs from network to
network, but usually maintains a relatively consistent average over an extended period. A sudden and
drastic (short-term) change in the distribution of ICMP echo packets or TCP control packets is
historically indicative of malicious behavior, if not an outright attack.
Volume anomalies
Network Security Platform also tracks rapid increases in the volume, or intensity, of traffic.
To simplify the analysis of volume anomalies, the self-learning algorithm categorizes all packets into
one of the following eight types:
•
IP fragment
•
TCP SYN and FIN
•
ICMP echo (request and reply)
•
TCP RST
•
All other ICMP
•
Non-TCP/UDP/ICMP
•
UDP
McAfee Network Security Platform 8.1
IPS Administration Guide
423
16
Denial-of-Service attacks
DoS attack detection mechanism
Percentiles
One of the methods that the Network Security Platform uses to deal with volume anomalies is to
establish thresholds based on packet rate and burst size for different packet types. Changes to these
established thresholds indicate threats and are dealt with accordingly.
To measure volume changes over time, Network Security Platform establishes two percentiles for each
of the packet types. For a given packet type, the Sensor looks at the distribution of the following:
•
Short-term packet rate
•
Traffic burst size
The Sensor analyzes these distributions to establish thresholds that the short-term averages must not
typically exceed. For example, Network Security Platform might determine that, for a given packet
type, 95 percent of the short-term profiles averaged a rate of X packets per second or fewer, and a
packet size of Y bytes or smaller. When the average rate exceeds X packets per second and the pocket
size exceeds Y bytes, Network Security Platform analyzes the significance of change. If the change is
significant and matched a threat perception, an alert is raised.
Only one statistical anomaly alert is sent per attack every two minutes.
Alert details
DoS related alerts are listed in the Alerts page of the Threat Analyzer. DoS related alerts are either
alerts relating to threshold violations or statistical attacks.
•
Simple threshold alerts are those in violation of DoS threshold mode settings.
•
Statistical attacks are those in violation of DoS learning mode settings.
To view details of a specific alert, right-click an attack instance and click Show details.
Figure 16-9 All Alerts page of Threat Analyzer
424
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
The Alert Details page gives a clearer picture of the key information related to the attack. The
information can then be used to augment your policy settings and/or to initiate a response action.
Figure 16-10 Alert Details page
The Alert Details page displays alert details that are specific to a type of attack. Hence, the information
displayed varies from one type of attack to another.
Some alert details relating to DoS attacks are:
Simple Threshold Alerts
Simple Threshold alerts are those in violation of DoS threshold mode settings.
•
Threshold ID — This ID corresponds to where this threshold attack is listed in the DoS Threshold Mode
catalog.
•
Observed Value — The number of times the instance occurred. Since an alert was sent, this value is
larger than the threshold value.
•
Threshold Duration — The time limit value set within DoS threshold mode customization for the attack
instance. This complements the Threshold Value. This duration is run to the end to capture all
instances within the time limit rather than stopping after the first value over the threshold is
detected.
•
Threshold Value — The limit set within DoS threshold mode customization for the attack instance and
complements the Threshold Duration.
Statistical Alerts
McAfee Network Security Platform 8.1
IPS Administration Guide
425
16
Denial-of-Service attacks
DoS attack detection mechanism
Statistical attacks are those in violation of DoS learning mode settings.
•
Measures — Displays bar graphs with packet rate data relating to the violated learning mode
measure. The violated measures are displayed with the corresponding packet rate over the last 10
minutes. The graph displays the learned long-term rate (as established by the DoS profiling
process) against recent activity, or short-term rate. The short-term rate is for the most recent 10
minutes approximately. When the short-term rate is greater than the long-term rate and exceeds
the specified response sensitivity (low, medium, or high - from DoS Learning Mode settings), an alert is
generated.
The percentage value represents the percentage of all traffic for which the noted measure
accounted. For example, if the normal percentage for IP fragments is approximately 2.5 percent,
then IP fragments make up 2.5 percent of all traffic through the monitored segment. If the
percentage of fragmented IP packets in the traffic during an interval was significantly higher than
the established long-term percentage, it indicates an IP fragment flood attack.
•
426
Packet Rate — Displays the violated measure's packet rate for the last minute when the alert was
raised. Packet rates are shown in five-second intervals.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
•
16
DoS IP Range — Displays the ranges of IP addresses, both source and destination that were involved
in the DoS attack.
•
The packet type and total number of packets that were a part of the attack are also noted.
•
Min refers to the first address in the range and Max refers to the last address in the range.
•
Total Packet Count is the number of DoS packets seen from the given source and destination range.
This includes both benign and attacking packets. All packets of various packet types, such as
TCP SYN, destined to the particular network are displayed in the alert.
Figure 16-11 DoS IP range dialog
The first DoS alert shows packets counts received for 5 seconds before the alert. The subsequent
suppressed alerts show the number of packets received since the last alert.
If you choose to drop packets, the Sensor drops only the bad packets. Thus, the Sensor might not
always drop packets from what is determined as a good source IP address.
Blocking DoS attacks
A Sensor can be configured to block traffic when statistical anomalies occur. Blocking DoS traffic is
more involved than blocking normal exploits because the source is often unclear. For example, the
success of a distributed attack might depend on the quantity of compromised hosts generating traffic
together, rather than a single host generating a significant volume on its own. This complicates the
blocking process because a Sensor cannot merely block hosts that individually generate large volumes
of traffic. Moreover, DoS attack tools typically generate traffic with spoofed IP addresses, so
attempting to block them gains nothing and wastes resources.
McAfee Network Security Platform 8.1
IPS Administration Guide
427
16
Denial-of-Service attacks
DoS attack detection mechanism
Instead, Network Security Platform classifies source IP addresses as IP profiles to differentiate
between good and bad hosts. It then uses these IP profiles to determine a blocking scheme for the
Sensor .
•
The Sensor must be in detection mode to detect and block attacks.
•
You can block DoS attacks only when the Sensor is deployed in the inline mode.
How blocking works for DoS attack traffic
A DoS policy applies to inbound, outbound, and bidirectional traffic. Inbound traffic is that traffic
received on the port marked outside, that is, originating from outside the network, in inline mode.
Typically inbound traffic is destined to the protected network, such as an enterprise intranet. Outbound
traffic is that traffic sent from a system in your intranet, and is on the port marked inside, that is,
originating from inside the network, in inline mode.
Bidirectional attacks reflect changes in the distribution of ECHO requests and replies in both inbound
and outbound. For example, if the Sensor normally sees 50 percent inbound replies and 50 percent
outbound replies, but then the distribution changes to 70 percent / 30 percent, the change might raise
an alert.
There are also learning mode attacks that do not have a directional association, specifically ICMP ECHO
anomaly and TCP control anomaly. Note that Sensors can only raise an alert in case of ICMP echo
anomaly and TCP control anomaly attacks but cannot block them, even when in inline mode.
The Sensor applies the outbound or inbound DoS policy depending on the traffic direction, which is
determined through the Sensor cabling and port configuration. The drop attack packets response
action must be enabled by traffic type (protocol type) within the DoS policy.
When the Sensor detects an attack traffic condition, the block action will persist until the attack
condition ends and will repeat whenever the attack condition is present.
Block DoS attacks in the Threat Analyzer
All attacks, except ICMP echo anomaly and TCP control anomaly, can be configured to be blocked from
within the Real-time or Historical Threat Analyzer.
Task
1
In the Alerts page of the Threat Analyzer, right-click an alert and click Show Details.
The alert details for the selected alert are displayed.
2
Select Actions | Edit Attack Settings | Default Attack Settings.
Default Attack Settings customizes the attack definition for all the IPS policies. If you select Local Policy,
the customization applies only to the local IPS policy, that is the customized IPS policy applied on
the corresponding interface or subinterface. If you select Baseline Policy, the customization applies to
the IPS policy that is applied at the admin-domain level.
Figure 16-12 Blocking attacks in the Threat Analyzer
428
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack detection mechanism
16
3
In the Edit Attack Detail for Attack window, select Customize Blocking Setting | Blocking (Drop DoS attack packets of
this attack type when detected) if you want to drop DoS packets when they are detected.
4
Deploy configuration changes for the corresponding Sensors for the blocking to take effect.
5
You can also customize the blocking of DoS traffic for a specific alert, without affecting the attack
definition in any of the IPS policies.
For this option, click Start DoS blocking from the Actions menu.
6
Enter the duration for which you want the DoS traffic to be blocked in Enable DoS blocking for the next __
minutes.
Figure 16-13 Start DoS blocking dialog
7
Click Start.
The Sensor drops the traffic for the specified time if the interface/subinterface, direction, and DoS
conditions match.
Verify blocked DoS attacks using the Threat Analyzer
Alerts reflecting a DoS condition continue to be sent to the Threat Analyzer for the duration of the
attack. In Threat Analyzer, the result status displays Blocking activated for the duration of the attack
condition.
Drop DoS attacks from the Threat Analyzer
The DoS policy enables you to selectively drop DoS learning mode attacks. However, if you have not
set the response action accordingly, the Threat Analyzer provides the ability to drop further DoS
attacks after a recent attack has been detected.
Exploit-based DoS attack detection
Exploit or vulnerability-based attacks are manifested in attack signatures, which Network Security
Platform uses to detect specific exploit attacks.
A signature is a profile of an attack. Detection of specific attacks is possible through signatures.
Network Security Platform also uses exploit signatures for DoS attacks that are not caused by
traditional means such as volume overload. For example, the HTTP: Microsoft IIS...SLASH...
DenialofService exploit identifies a single request that prevents older IIS servers from responding to
clients until they are restarted.
The Sensor uses signatures to perform different levels of traffic processing and analysis. Network
Security Platform signatures operate on a framework of flows, protocol parsing, and packet searches
to detect vulnerability-based DoS attacks and attacks using DDoS attack tools. For example, Network
Security Platform's detection mechanisms enable a signature to identify every HTTP traffic flow, every
McAfee Network Security Platform 8.1
IPS Administration Guide
429
16
Denial-of-Service attacks
DoS attack detection mechanism
HTTP traffic flow using the GET mechanism, every HTTP traffic flow using GET with /cgi‑bin/calendar
.pl as the path and even every GET with that path and a parameter named month with a value of
February.
Network Security Platform supports the aggregation of multiple signatures into every attack. Each
signature within an attack can be more or less specific to identify everything from generic network
activity that affects a given platform in a particular way to a specific piece of code that has very
specific and identifiable effects. Based on their specificity and severity, signatures are assigned
different confidence and severity values.
Flows
At the highest level, the Network Security Platform addresses UDP and TCP traffic based on the
concept of a flow. Flows are defined by their protocol (either UDP or TCP), source and destination
ports, and IP addresses of their endpoints. UDP does not contain the concept of state that TCP does,
so the Sensor implements a timer-based flow context for UDP traffic. After dividing traffic into flows,
the Sensor makes use of port mapping, or in the case of traffic running on non-standard ports,
intelligent protocol identification, to pass each flow to the appropriate protocol parsing mechanism.
It is also worth noting that Network Security Platform provides you with the ability to specify whether
your signature will look at the complete flow, one direction of the flow, or restrict itself to data
occurring within single packets of the flow. Precise control of this detection window is necessary for
accurate detection of attacks.
Protocol parsing specifications
Protocol specifications (Network Security Platform's protocol parsing mechanisms) parse through
network flows to validate traffic and divide it into protocol fields, which might then be actively tested
against Network Security Platform-supplied attack definitions or Custom Attack Definitions. By dividing
protocol traffic into the appropriate fields, Network Security Platform can perform matches against the
most specific field or sub-field pertinent to an effective attack, thus supporting signatures with very
low false-positive rates. Since the parsing process is fully stateful, it allows detection of anomalies in
the protocol's behavior. Additionally, this parsing makes it possible to provide an additional benefit to
signature writers in the form of qualifiers. Qualifiers are tests that are embodied in the name of a
particular protocol field. For example, rather than specifying that an HTTP request method must be
GET, the Network Security Platform system allows the use of http-get-req-uri as the name of the
field, saving the requirement of providing that test in the signature, and the Sensor from having to
perform an extra pattern match.
Packet searches
Traffic flows that are not identified as belonging to any particular protocol are passed to the Packet
Search Protocol Specification Engine for further parsing. Network Security Platform presents each
direction of the flow to Network Security Platform-defined attacks and to any Custom Attack
Definitions. Tests against packet search traffic typically take the form of specific ordered pattern
matches to prevent false positives and performance problems.
Where signatures fit
Signatures tie together elements of flows, protocol parsing, and packet search framework to derive
specific fingerprints for network traffic from smaller building blocks. In essence, signatures are like
DNA tests. They can identify both specific people and relatives of that person. In the
intrusion-detection case, the relatives might be a collection of buffer overflow attacks against a certain
piece of software, and the particular person would be a specific piece of exploit code.
While the two are not greatly different, Network Security Platform adopts a convention of
differentiating between anomaly-based attack signatures (not to be confused with anomaly-based
detection for DoS attacks) and signatures pertaining to a specific attack. The main difference is that
430
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Layer 7 DoS protection for web servers
16
while anomaly-based signatures examine the network for unexpected or non-conforming behavior,
signatures pertaining to specific attacks will often look for a very particular indicator, such as a flag
with a particular value, or a specific string's presence. Signature-based anomaly attacks know what to
expect in normal traffic, and trigger when they get something else. Normal attack signatures look for
specific misbehavior. When defining attacks to detect and protect from vulnerabilities, a blended set of
signatures are often defined which check for behavioral anomalies as well as specific exploit strings.
Using this mechanism, all possible attempts to exploit the vulnerability can be detected.
Layer 7 DoS protection for web servers
Network Security Platform provides protection from DoS attacks at various TCP/IP levels, including
DoS protection at layer 3, connection-limiting policies at layer 4, and web server protection at layer 7.
A layer 7 DoS attack is difficult to detect when compared to DoS attacks at other layers because such
an attack is often perpetrated through the use of an upsurge of HTTP requests, where the attacker
looks like a legitimate connection, and is therefore passed on to the web server. There are multiple
HTTP requests at the same time, and these legitimate HTTP requests are mixed in with the attack.
With the growth in bots, HTTP application-level DoS attacks have become more common and even
more difficult to detect. bots can be programmed to launch DoS attacks against a particular domain or
URL, and these requests appear as normal HTTP requests originating from a browser, thereby making
it difficult to differentiate bot traffic from normal traffic.
Multiple types of DoS attacks range from attacking web server infrastructures to targeting a particular
URL/path resulting in huge file downloads and slowing down the web servers. Since bot traffic pattern
is different depending on the botnet technology and the attack classes, Network Security Platform
aims at allowing users to customize different response actions based on configured thresholds.
McAfee Network Security Platform 8.1
IPS Administration Guide
431
16
Denial-of-Service attacks
Layer 7 DoS protection for web servers
Defending against Layer 7 DoS attacks usually involves a mechanism to configure different HTTP
response actions based on traffic volume anomaly. Network Security Platform deals with DoS attacks
in layer 7 by employing the HTTP challenge-response approach based on the traffic volume anomaly
with different threshold methods. A three-pronged protection approach is used consisting of attack
identification, response action, and the defensive action.
Figure 16-14 DoS protection at layer 7
You can view the status of L7 DoS using the show l7ddosstat command.
Using the Manager, the layer 7 DoS protection for web servers allows you to configure protection
options on the web server side as well as the web client side.
This feature is available on Sensor models M-3050 and higher.
Web server protection settings
The Sensor provides the ability to define threshold values to limit the maximum simultaneous
connections to web servers, minimizing connection-based DoS attacks on your network. The number
of active HTTP connections coming to the server that are less than or equal to the defined threshold
value are allowed, whereas the connections exceeding the threshold are dropped.
The connections to the web servers are limited based on the defined threshold value. The threshold
value is defined as maximum simultaneous connections.
432
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Layer 7 DoS protection for web servers
16
After the threshold is defined, the Sensor limits the maximum connections based on the configured
values. An alert is sent each time the connections exceed the defined threshold value and excess
connections are dropped. This ensures that the web servers do not become unavailable due to
overload.
The Sensor provides you with a defense mechanism to recover from a DoS attack. You can configure
the option to prevent slow connection web server attacks.
The logic behind this option is that the HTTP protocol is designed for short connections. Five minutes is
assumed to be a long time and a connection alive for more than five minutes is assumed to be a slow
connection. When this option is enabled, the Sensor sends a TCP reset to clear the 10 percent (of the
configured threshold) of the oldest active connections, alive for more than five minutes. This option
works only when your web resources are under a DoS attack. For example, if the configured threshold
is 10000, then 1000 active connections are closed. If the Sensor finds that there are only 500
connections alive for more than five minutes, then only 500 are closed. This leads to some amount of
recovery from a connection flood. The client receives no indication of a connection drop. It appears to
be a connection timeout.
McAfee recommends that if your environment requires long term HTTP connections, do not use this
option.
To understand the working of the DoS protection options on the web server side, consider the
following scenario where the Sensor is deployed in the inline mode.
•
Configure the threshold for Maximum Simultaneous Connections Allowed to All Web Servers with a value of
10000.
•
Enable Prevent Slow Connection Web Server Attacks.
•
Push the configuration changes to the Sensor.
•
The Sensor monitors the connection requests to the web servers and detects an upsurge of
connection requests. Once the connection threshold is reached, the Sensor raises an alert. All
connections beyond the configured threshold of 10000 are dropped. You can view the alert details
in the Threat Analyzer.
•
The Sensor scans the active connections and identifies the connections alive for more than five
minutes as slow.
•
The Sensor sends a TCP reset to clear 10 percent of the oldest active connections, that is, 1000
active connections.
•
Use the show l7ddosStat command to verify the connection details.
Web client protection settings
You can use the URL rate limiting technique to control the rate of URL requests to all website paths per
second per IP address. The Sensor permits rate limiting of URL requests by limiting the number of the
requests that go to the web. URL requests that are less than or equal to the specified rate are allowed,
if the requests exceed the configured rate, an alert is raised.
You can configure to protect specific websites or apply protection to all websites. When you configure
specific websites to protect against DoS attacks, the Sensor considers only those HTTP requests that
contain these paths. Specifying paths optimizes the performance of the feature.
The Sensor provides you with a defense mechanism to detect the web client browser. You can use the
browser detection method. This option mitigates DoS attacks originated from bots. With this option,
you can send a challenge back to the user to determine if the HTTP requests are originating from valid
browsers or bots. You can configure an HTML or a Javascript challenge.
McAfee Network Security Platform 8.1
IPS Administration Guide
433
16
Denial-of-Service attacks
Layer 7 DoS protection for web servers
The logic behind this option is that bots have limited browser functionalities. When the Sensor sends a
challenge, the browser should send a legitimate response. If the response is legitimate, it is assumed
that the request is originating from a valid browser. The Sensor processes the response and
communicates back to the server.
If the request originated from bots, they might not understand the challenge sent by the Network
Security Platform and drop the connection request. When this happens, the Sensor quarantines the
host.
To understand the working of the DoS protection options on the web client side, consider the following
scenario where the Sensor is deployed in the inline mode.
•
Configure the threshold for Maximum URL Request Rate Allowed to All Website Paths with a value of 50.
•
Enable Web Client Browser Detection.
•
Select the Browser Detection Method as JavaScript Challenge. JavaScript based challenge/response
mechanism is used to detect a valid client browser.
•
Select all Website Paths to Protect.
•
Push the configuration changes to the Sensor.
•
The Sensor monitors the URL requests to websites and detects an upsurge of URL requests. Once
the URL request rate is reached, the Sensor raises an alert.
•
Excess connections from the same host, exceeding any URL/second threshold, are validated by
Javascript challenge mechanism. If the challenge response/refresh is successful, Sensor forwards
the request to server. If the challenge response/refresh is unsuccessful by attempting 3 times,
Sensor drops the request, resets the server and quarantines the host.
•
Use the show l7ddosStat command to verify the counters.
Configure Web Server - Denial-of-Service Protection at the
admin domain node
The Layer 7 DoS protection settings for web servers are disabled by default. You can configure the
Layer 7 DoS protection options in the parent domain at a global level and inherit these options in the
child admin domains (interfaces and subinterfaces). You can modify the inherited settings at the child
admin domains.
Task
434
1
Click the Devices tab.
2
Select the domain from the Domain drop‑down list.
3
Select Global | Default Device Settings | IPS Devices | Web Server - Denial-of-Service Protection.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Layer 7 DoS protection for web servers
4
16
Configure the following DoS protection settings.
Table 16-2 Web Server - option definitions
Option
Definition
Web Server
Maximum Simultaneous
Connections Allowed to All Web
Servers
Prevent Slow Connection Web
Server Attacks
Specifies the threshold for maximum connections allowed to all web
servers from a host.
When connection limiting rules are created, whichever has smaller
threshold raises an alert first.
Enable this option to close 10% of the oldest slow open connections.
This option is disabled by default.
Web Client
Maximum URL Request Rate
Allowed to All Website Paths
Specifies the threshold for maximum URL requests allowed to all
website per second.
Enable Web Client Browser
Detection
Enable this option to send a challenge back to the user to determine if
the HTTP requests are originating from valid browsers or Bots.
Browser Detection Method
The detection methods use the challenge/response mechanism to
detect a valid client browser. The options are HTML Challenge and
JavaScript Challenge.
This option is not supported in span and tap modes.
Website Paths to Protect
Specify website paths to which the HTTP requests are sent, to be
protected. You can protect All or Specific paths.
A maximum of 64 website paths per Sensor and 8 website paths per
interface can be protected.
Website Paths to Protect
New Path
Enter the website paths that you want to protect in New Path and click
Add.
For example, if you specify /mcafee.com as a path, then the Sensor
inspects only those requests that contain /mcafee.com.
5
Maximum URL Requests/Second
Specify the maximum URL requests allowed to the protected website
path.
Current Paths
Displays the list of the protected website paths. To delete a path,
select it and click Delete.
Click Save.
Configure Web Server - Denial-of-Service Protection at the
interface level
Web Server - Denial-of-Service Protection is disabled by default. You can enable it in the Protection
Profile page of an interface or subinterface.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop‑down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop‑down list.
McAfee Network Security Platform 8.1
IPS Administration Guide
435
16
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
5
Select IPS Interfaces | <Interface Name> | Protection Profile.
The Protection Profile page appears.
6
In the Protection Options section, click Web Server - Denial-of-Service Protection.
7
Enable the protection option for inbound and/or outbound traffic.
8
To inherit settings from the parent domain, enable Inherit the Default Settings?.
9
Specify the required settings in the corresponding fields.
10 Click Save.
Manage DoS attack definitions for an interface and a
subinterface
All of the provided IPS policies include protection against DoS attacks. There is no separate policy for
DoS attacks. You can customize the DoS attack definitions just like you customize any of the exploit
attack definitions in the IPS policies. For a given signature set, the same DoS attack definitions with
the same configuration is included in all the pre-defined IPS policies. DoS customization is key to
protecting a specific host or server from a concentrated DoS attack.
Network Security Platform enables extremely granular DoS protection: you can customize DoS attack
definitions for the Sensor, interface, and interface separately. At the Sensor level, customize the attack
definitions in the baseline IPS policy. At the interface and subinterface levels, customize the local IPS
policy. Therefore, you can apply customized DoS attack definitions that is exclusive for a given VLAN
or CIDR traffic for a specific interface.
Customize DoS attack definitions for an interface or
subinterface
At the interface and subinterface levels, the DoS attack definitions are inherited from the baseline IPS
policy applied at the Sensor level. This includes the DoS learning attack definitions as well as the DoS
threshold attack definitions. Any customization in the baseline IPS policy applies automatically at the
interface and subinterface levels. You can further customize these attack definitions in the local IPS
policy exclusively for the interface or subinterface. Just like any other customization in a local IPS
policy, these are applicable only to that interface or subinterface. Also, note that the customization
done at an interface is not inherited by the corresponding subinterfaces, unlike the customization at
the Sensor, which are inherited at the interfaces and subinterfaces.
The process of customizing attack definitions at interfaces and subinterfaces are similar.
Task
436
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
5
16
Select IPS Interfaces | <Interface_Name or Sub-interface_Name> | Protection Profile.
In the IPS Policy section, you can view the applied Baseline IPS Policy .
Figure 16-15 The applied Baseline IPS policy
6
Select Edit for Local Policy Actions and click Go.
If this is the first time you are customizing the IPS policy for the interface, click Use a Local Policy to
view the Local Policy Actions options. All the attack definitions in the applied IPS policy are listed in the
Attacks tab of the IPS policy editor.
7
Select Attack Category from the list adjacent to Group By.
Figure 16-16 Group the attack definitions by Attack Category
The attack categories along with the number of attack definitions per category are listed.
McAfee Network Security Platform 8.1
IPS Administration Guide
437
16
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
8
Double-click DoS Learning Attack or DoS Threshold Attack based on the DoS attacks that you want to
customize.
Figure 16-17 Number of attack definitions by Attack Categories
The attack definitions belonging to the DoS attack category you selected are listed. This includes
inbound, outbound, and bidirectional attack definitions.
DoS Learning Attack and DoS Threshold Attack are the categories that correspond to DoS attack definitions.
9
Right-click the attack that you want to customize and select Edit.
You can also select multiple attacks and select Bulk Edit from the right-click menu. For the sake of
explanation, assume that you are customizing a single attack.
10 Customize the DoS attack definition in the Edit Attack Details page.
11 Click OK.
12 To customize more attacks belonging to the currently selected attack category, repeat the previous
2 steps. To edit attacks belonging to a different Attack Category, click All (clear drilldown) and repeat
from step 5.
13 After you have customized all the required attack definitions, click Save.
The Summary page opens.
14 Review the summary of changes and click Finish to save your changes.
438
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
16
From now on, if you open the IPS Policy editor to edit the Local IPS policy, the customized attacks
can be viewed in the Customized tab. In the Protection Profile page, you have the following options for
Local Policy Actions:
•
Edit — Allows you to make changes to the local IPS policy
•
Reset — Resets the customizations to the local attack definitions. Select Reset and click Go to
reset the customizations to the local attack definitions. A warning message is displayed. Click OK
to confirm.
•
Merge — Merges the local policy with the baseline policy. You can select Merge and click Go to
merge the local policy with the baseline policy. A warning message is displayed. Click OK to
confirm.
If you click the integer value (if greater than 0), you can automatically go into edit mode with the
customized attacks showing in the foreground.
Figure 16-18
Options available after customization
15 Deploy the configuration changes to the required Sensors for the changes to take effect.
Tasks
•
View the applied DoS profiles at a Sensor resource on page 439
View the applied DoS profiles at a Sensor resource
The DoS Profile page of an interface (IPS Interfaces | Interface-x | DoS Profile) details the current status of DoS
learning mode policies applied to an interface. DoS policy was inherited from the domain upon Sensor
addition, but might have changed due to one of the following:
•
Application of a different policy.
•
Creation of one or more custom DoS IDs for an interface.
At the Interface-x level, you cannot see status for DoS IDs created within a subinterface. The view
at this level is strictly for the parent and direct child relationship. For more information on child DoS
policies of a subinterface, refer to Viewing the applied DoS policies of a sub-interface section.
Figure 16-19 View DoS Profile
McAfee Network Security Platform 8.1
IPS Administration Guide
439
16
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
In the DoS learning mode, a profile is built over a 48-hour period to determine the normal traffic
pattern. Once the initial learning is complete, the Sensor detects traffic that is outside of the normal
parameters while continuing to take measurements of network traffic and adjusting the profile
accordingly. Activity outside of the normal parameters raises an alert.
Task
440
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
5
16
Select IPS Interfaces | <Interface-x Name> | DoS Profile. The fields are as follows:
Table 16-3 Option definitions
Option
Definition
Profile
The subinterface or VLAN/CIDR ID where a DoS profile was applied. Default NI refers
to all traffic that is not a part of an interface subdivision, that is, subinterface, VLAN
tag, or CIDR block.
Status
Lists whether the policy is currently learning the network behavior or actively
detecting. Learning means the initial traffic profile is being created by determining a
normal traffic baseline. This learning period requires 48 hours. Detection means the
profile has finished the initial learning period and traffic checking for abnormal levels
is in progress.
Transition Time The exact time when the learning profile started analysis or when the active
detection for the learning profile began. The Status field indicates which process is
currently operating.
6
Optionally, select a Dos ID and click View to display rate data for the measures in the DoS profile
applied to the selected DoS ID.
McAfee Network Security Platform 8.1
IPS Administration Guide
441
16
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
You can change the measure by toggling the Select a Measure drop-down list and clicking View. To
return to the Applied Policy Detail table, click Back.
Figure 16-20 DoS Detection Status sub-tab
Tasks
•
View the applied DoS policies of a subinterface on page 442
View the applied DoS policies of a subinterface
The DoS Profile page of a subinterface ( Sub-interface-x | Sub-Interface | DoS Profile) provides operational details
on the custom DoS policies applied to a subinterface. DoS policy was inherited from the interface upon
subinterface creation, but might have changed due to one of the following conditions:
442
•
Application of a different policy for the subinterface.
•
Creation of one or more custom DoS policies for a subinterface. This was achieved by performing
the Manage Custom action for an entire subinterface, for individual VLAN/CIDR IDs within a
subinterface, or for a CIDR addresses within a VLAN or CIDR ID.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
16
In DoS learning mode, a profile is built over a 48-hour period to determine the normal traffic pattern.
Once the initial learning is complete, the Sensor detects traffic that is outside of the normal
parameters while continuing to take measurements of network traffic and adjusting the profile
accordingly. Activity outside of the normal parameters raises an alert.
The Applied Policy Detail table displays the parent-child (subinterface or subinterface-DoS IDs)
relationship with learning mode status values for the subinterface and each of its direct children
respectively. This is particularly useful if you have expanded policy application through the Manage
Custom action and you want to determine the status of the newly applied profile.
Task
1
Select Sub-interface-x | IPS Sub-Interface | DoS Profile.
Table 16-4 Option definitions
Option
Definition
Profile
The subinterface where DoS policy was applied. Default NI refers to all traffic that is
not a part of a subinterface subdivision, that is, DoS ID for a VLAN tag or CIDR
address within a subinterface.
Status
lists whether the profile is currently learning or detecting. Learning means the initial
learning profile is being created to determine the normal traffic baseline. This
learning period requires 48 hours. Detection means the profile has finished the initial
learning period and traffic checking for abnormal levels is in progress.
Transition Time The exact time when the learning profile started analysis or when the detection for
the learning profile began. The Status field indicates which process is currently
operating.
2
Optionally, select a DoS ID and click View to display rate data for the measures in the DoS profile
applied to the selected DoS ID.
You can change the measure by toggling the Select a Measure drop-down list and clicking View. To
return to the Applied Policy Detail table, click Back.
Customized DoS policy in a network
The following table summarizes the rules for creating custom DoS policies in a network.
If you customize DoS:
Then...
At the Interface level, for the entire interface or for a VLAN or
CIDR ID (and a subinterface has not been created)
You cannot create subinterfaces
for the interface.
At the SubInterface level, for the entire subinterface or for a
VLAN or CIDR ID within the subinterface
You cannot customize DoS at the
interface level.
For a VLAN interface with multiple VLAN tags, you can do one of the following:
•
Customize the inherited DoS policy and create multiple DoS policies for each of your VLAN tags. If
you create DoS policies for your VLAN tags at the interface node, you cannot create subinterfaces
for your VLAN tags.
•
Customize the inherited DoS policies and create multiple subinterfaces which can then have custom
DoS policies. If you created subinterfaces for your VLAN tags, you cannot create custom DoS
policies for any VLAN tags at the interface level.
McAfee Network Security Platform 8.1
IPS Administration Guide
443
16
Denial-of-Service attacks
Manage DoS attack definitions for an interface and a subinterface
•
For a CIDR interface with multiple CIDR-based addresses, you can do one of the following:
•
Customize the inherited DoS policies and create multiple DoS profiles for each of your CIDR
addresses
•
Customize the inherited DoS policies and create multiple subinterfaces which can then have
custom DoS policies. If you created subinterfaces for your VLAN tags, you cannot create custom
DoS policies for any VLAN tags at the interface level.
In this example, suppose a Sensor is in SPAN mode, monitoring the traffic transmitting between the
floors of a building. Sensor port 1A is the interface number.
Figure 16-21 DoS policy customization example
The above displays various custom DoS implementations. The traffic type scenarios that follow explain
DoS policy customization options for each of the three interface types.
Customize DoS policy for a dedicated interface
Suppose port 1A's traffic type is dedicated. In this situation, you can:
444
•
Customize the inherited DoS settings for all of the traffic the interface monitors.
•
Create multiple DoS policies for multiple CIDR networks. Referring to the diagram in the
Customized DoS policy in a network section, you can create three unique DoS policies for
192.168.0.0/24, 192.168.1.0/24, and 192.168.2.0/24. Once these unique DoS instances have
been created, the rest of the interface traffic is protected by the inherited DoS settings.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
16
Customize DoS policy for a VLAN
Suppose instead that Port 1A's traffic type is VLAN, and that you have added VLAN IDs 1-6 to your
interface. In this situation, you can:
•
Create multiple DoS policies for each VLAN ID in the network. In this instance, you can create
unique DoS policies for VLAN 2, VLAN 4, and VLAN 5. All other traffic in the interface is protected
against DoS by the inherited DoS policy settings; the inherited settings can be customized.
•
Create a subinterface. You combine VLANS 2, 4, and 5, and call the subinterface VLAN-245.
•
Create a DoS instance for an individual VLAN ID and the entire subinterface for all other traffic, for
example, just VLAN 2 and the entire VLAN-245. You can later create DoS instances for VLANs 4 and
5.
Customize DoS policy for a CIDR
Suppose that port 1A's traffic type is CIDR. You can do one of the following:
•
Create multiple DoS policies for each CIDR network ID and the rest of the interface's traffic. In this
instance, you can create unique DoS policies for 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24,
and the entire 1A.
•
Create a subinterface. You combine 192.168.0.0/24 and 192.168.1.0/24, and call the subinterface
CIDR-0010.
•
Create a DoS instance for an individual CIDR ID and the entire subinterface for all other traffic, for
example, just 192.168.0.0/24 and the entire CIDR-0010.
Denial-of-Service profile advanced scanning
What is a DoS profile?
A DoS profile is an analysis of network traffic with reference to the normal traffic flow captured during
the learning period of a Sensor. A DoS Profile displays the current status of DoS learning mode policies
applied to a Sensor, as well as its interfaces and subinterfaces. In DoS learning mode, a profile is built
to determine a normal traffic pattern. Once this profile is learned, the Sensor alerts for traffic that is
outside of the normal parameters. The profile is continually being built, thus baseline levels adjust
over time.
The Manager displays the learning mode status values for the Sensor and each interface, respectively.
This is particularly useful if you have changed policy application per interface and you want to
determine if the new profile is being built or if it is actively detecting abnormal traffic conditions.
DoS profiles of the selected Sensor are displayed in the DoS Profiles page.
DoS parameters are configured within each IPS policy or by creating a custom DoS policy at the
interface or subinterface level.
View the DoS profiles of a Sensor
The DoS profiles show a comparative display of short-term and long-term distribution for the selected
profile.
McAfee Network Security Platform 8.1
IPS Administration Guide
445
16
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select Policy | Denial of Service | Profiles.
The Dos Profiles page details the current status of DoS learning mode policies applied to an interface
or sub-interface. DoS policy was inherited from the domain upon Sensor addition but might have
changed due to the application of a different policy at the interface or sub-interface level.
Figure 16-22 DoS Profiles tab
Table 16-5 Option definitions
Option
Definition
Profile
The sub-interface or VLAN/CIDR ID where a DoS profile was applied. Default NI refers
to all traffic that is not a part of an interface subdivision, that is, sub-interface, VLAN
tag, or CIDR block.
Status
Lists whether the profile is currently learning or detecting. Learning means the profile
baseline is being built. Active means the learning profile has finished and traffic is
being checked against the baseline.
Transition Time The exact time when the learning profile started analysis or when the active
detection for the learning profile began. The Status field indicates which process is
currently operating.
446
McAfee Network Security Platform 8.1
IPS Administration Guide
16
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
6
Select a DoS profile and click View.
Figure 16-23 DoS profile - Advanced Scanning
7
Optionally, select the direction (Example: Inbound) and a measure (example: tcp-control) to
display rate data for the measures in the DoS profile applied to the selected interface.
When reading the chart, it is helpful to remember that:
8
•
The long-term profile is the compilation of the short-term profiles.
•
The horizontal axis contains buckets of the various packet rates.
•
The vertical axis indicates the percentage of those rates falling into each bucket.
Click Close to go back to the Dos Profiles page.
Configure Denial-of-Service profile limits
The limit to the quantity of DoS profiles that can be configured per Sensor is unique for each Sensor
model.
The details are as follows:
I-Series — Maximum DoS profiles supported
I-4010
I-4000
I-3000
I-2700
I-1400
I-1200
5,000
5,000
5,000
300
120
100
M-Series — Maximum DoS profiles supported
M-8000
M-6050
M-4050
M-3050
M-2750
M-1450
M-1250
5,000
5,000
5,000
5,000
300
120
100
NS-Series — Maximum DoS profiles supported
NS9100
NS9200
NS9300
5,000
5,000
5,000
McAfee Network Security Platform 8.1
IPS Administration Guide
447
16
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
DoS data management
Using the DoS Data Management page, you can configure the DoS learning mode profile to restart or load
from a previous profile. 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.
Since a DoS profile can be configured for both learning and threshold modes, the Sensor keeps
statistics for both modes. For 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 48 hours. 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.
For threshold mode, the Sensor keeps track of the threshold limits you enabled for specific attacks.
Together these two modes create one profile, which is saved to your Sensor's flash and can be
uploaded to the Manager for future re-use. You can upload this saved profile later if you feel the
baseline that had previously been created was more effective than a current profile.
DoS Copy feature is not supported on M-series Sensors.
Manage DoS profiles
The DoS Data Management page enables you to manage the DoS learning mode policies on a Sensor.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select Policy | Denial of Service | Data Management.
The last DoS profile uploaded from the Sensor to Manager is listed under DoS Profiles on Manager.
6
Select one action from one of the following headings:
DoS Profile Learning
•
Rebuild the DoS Profiles — Starts the learning process from scratch. The profile that has just been
learned is erased, and a new profile is built. To start the learning process, select this option and
click Update.
Typically, this is only required when:
•
It is known that a DoS attack occurred during the initial learning phase, contaminating the
long-term profile.
•
There has been a significant change in network traffic, for example, an overhaul to the
routing infrastructure.
When a port runs in learning mode, it does not analyze traffic for DoS attacks. You can infer
whether DoS attack has occurred during the initial phase or not by reading situations specific to
your network.
448
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
•
16
Force the IPS Sensor into Detection Mode — You can force a Sensor into detection mode before the
normal 48-hour minimum learning period. This option must be reserved for testing and
troubleshooting. .
McAfee recommends performing a re-learn profile when there is a network change, for example
if you moved Sensor from a lab environment to a production environment. Re-learning a profile
is also recommended if there is a configuration change, that is you changed the CIDR block of a
subinterface that causes a significant sudden traffic change to an interface or subinterface for
which a profile has already been established (or in the process of initial learning). Without doing
so, the Sensor might give false alarms or fail to detect attacks during a time period when it is
adapting to the new network traffic conditions.
There is no need to re-learn a profile when network traffic increases or decreases naturally over
time (for example, an eCommerce site that is getting more and more customers, thus its web
traffic increases in parallel), since the Sensor can automatically adapt to it.
Figure 16-24 DoS Data Management area
Manage DoS Packet Copying Actions
Enable/disable the forwarding of DoS packets, which would have been dropped if in inline mode,
through a Sensor response port. You can then use a sniffing device to collect the dropped packets
McAfee Network Security Platform 8.1
IPS Administration Guide
449
16
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
from the response port. Analysis of dropped packets might provide insight as to the validity of an
attack as well as provide further research for your ongoing security configuration.
•
Enable copying of DoS packets to Response port(s)
•
Disable copying of DoS packets to Response port(s)
The following is a list of Sensors and corresponding response ports, respectively, to use if you
Enable copying of DoS packets to Response port(s):
I-1200, I-1400: R1*
I-2700: R3
I-4000: R1, R2, AUX1**, AUX2**
I-3000, I-4010: R1, R2, R3, R4
* If Sensor failover is enabled on I-1200 or I-1400, this response port is already in use and
cannot be used for copying DoS packets.
** Used only for DoS copy function.
DoS Profile upload and restoration
In most circumstances, there is no need to upload and restore profiles. The exceptions include:
•
The Sensor fails to detect an attack. In this case, the Sensor mistakenly learns the bad traffic
pattern as good. A previous profile can be restored to replace the contaminated one, if one was
saved.
•
The Sensor is used for testing that skews the long-term profile. To bring the Sensor back in
good standing, a profile is saved, the testing is performed, and the previously saved profile is
restored.
•
A change to the quantity of interfaces/subinterfaces is made, but the change needs to be
reversed. For example, you add a new subinterface, which also changes the quantity and
makeup of DoS profile. You then decide to back out of the change. Restoring a profile eliminates
the requirement to go through the re-learning phase.
Rebooting a Sensor does not return it to learning mode. A Sensor stores long-term data and picks
up where it left off when the reboot started.
•
450
Upload a DoS Profile (device to Manager): uploads all of the learned profiles on a Sensor's flash to
Manager. To upload a Sensor's DoS profiles to Manager, do the following:
•
Select Upload a DoS Profile (device to Manager).
•
Click Update. The Upload DoS screen opens with the Upload? field checked by default.
•
Click Upload DoS Profiles. A pop-up displays upload status.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Denial-of-Service profile advanced scanning
•
Click Close Window to close the status window after upload finishes.
•
Click Data Management to return to the main screen to view your uploaded file. One file is
uploaded for all interfaces, subinterfaces, or DoS IDs of a Sensor. This file is listed in the
"DoS Profiles on Manager" section (top) of the table.
16
You will have to wait at least 48 hours for the first learning profile to finish before you can
download a profile.
Figure 16-25 Uploading a DoS profile from a Sensor to the Manager
•
Restore a DoS Profile (Manager to device): downloads a DoS profile to the Sensor that has been
previously uploaded (saved) to Manager using the Upload a DoS Profile (device to Manager) option. The
uploaded profile is listed under the "DoS Profiles Uploaded from Sensor to Manager" heading. To
restore a DoS profile, do the following:
•
Select Restore a DoS Profile (Manager to device).
•
Click Update.
•
Select a DoS profile and click Restore.
•
(Optional) Select a DoS profile and click Delete to delete the profile.
•
(Optional) Select a DoS profile and click Export to export and save the profile to a client that
is not Manager server.
Figure 16-26 Restoring a DoS profile
DoS filter management
You can view and modify the drop/block packets responses that have been initiated for the DoS
learning mode profiles applied for all network identifiers (NIs) within a Sensor. A DoS filter, or blocking
rule, is similar to a firewall deny rule in that subsequent traffic that matches the filter parameters is
blocked from transmitting further through your network. A network identifier is a Network Security
Platform term relating to interface, subinterface, and DoS ID resources. DoS filters are applied
exclusively to DoS learning mode attacks.
A DoS filter can be initiated for any DoS learning mode attack, namely the measures within each
attack. Each enabled learning mode attack is a combination of traffic flow rate measures, such as the
rate of TCP control packets or UDP packets. When a learning mode profile has completed learning the
normal traffic behavior, the long-term measure volumes in this profile are matched against short-term
McAfee Network Security Platform 8.1
IPS Administration Guide
451
16
Denial-of-Service attacks
DoS attack prevention methods
volume calculations for each measure. If the short-term volume is outside of the long-term volume, a
statistical attack type alert is raised. Once a statistical alert has been raised, the Sensor can initiate an
automatic or manual response to block all subsequent packets of the violated measure.
•
For automatic dropping and blocking, you configure a DoS policy with the drop packets response
enabled for one or more measures and apply the policy to a Sensor interface in inline mode.
Automatic filters last as long as the short-term volume continues to violate the long-term volume.
•
For manual blocking, you must initiate the response from the Threat Analyzer for a generated
Statistical alert. For more information, see Blocking further DoS packets for statistical attacks.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select Policy | Denial of Service | Filters.
Do one of the following:
•
To delete a filter, select a filter and click Delete.
•
To refresh a filter, select a filter and click Refresh.
•
To extend a filter, do the following:
a
Select a filter and click Extend. The Add DoS Filter Time dialog opens.
b
Type the number of seconds to add to the Filter Time.
c
Click Save; click Cancel to abort.
Figure 16-27 Add DoS Filter
DoS attack prevention methods
Once DoS attacks have been detected, Network Security Platform offers the following methods to
block various types of DoS Attacks.
452
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack prevention methods
16
Table 16-6 DoS attack prevention recommendations
Attack
TCP SYN
Recommendation
Comments
SYN Cookies
You can configure SYN cookies in the Manager to accurately
block all attack traffic, while allowing all legitimate traffic.
Statistical Anomaly
TCP SYN or TCP FIN inbound or outbound attacks can be
blocked by configuring the TCP SYN or FIN Volume too high policy to
block such attacks, in both inbound and outbound traffic
using the IPS Policy Editor.
When used within an enterprise, Firewall access rules can be
configured in the Manager to allow traffic only from known
sources.
Configuring SYN cookies is more effective and deterministic
compared to statistical anomaly.
TCP Full
Connect
Connection Limiting
with McAfee GTI
Integration enabled
Statistical Anomaly
You can define a threshold value to limit the connection rate
or the number of active connections from each source. In
addition to this, you can also define rules to limit access
based on the connection rate, external hosts’ reputation, and
geo-location.
Statistical anomaly is based on data learnt over a time
window. For immediate prevention of connection based DoS
attacks, Connection Limiting would be more effective.
When used within an enterprise, Firewall access rules can be
configured in the Manager to allow traffic only from known
sources.
TCP
ACK/FIN/RS
T
Stateful TCP
Statistical Anomaly
This attack can be blocked by setting the TCP Flow Violation
to DENY_NO_TCB in the Manager.
TCP SYN or TCP FIN inbound or outbound attacks can be
blocked by configuring the TCP SYN or FIN Volume too high policy to
block such attacks, in both inbound and outbound traffic
using the IPS Policy Editor.
TCP RST attacks can be blocked by configuring the TCP RST
Volume too high policy to block such attacks, in both inbound
and outbound traffic using the IPS Policy Editor.
Alternatively, TCP RST flood can be blocked by setting the
TCP Flow.
McAfee recommends that you use stateful TCP to prevent
these attacks.
DNS Flood
DNS Protect
Connection Limiting
with McAfee GTI
Integration enabled
Statistical Anomaly
You can mitigate DNS flood attacks by using DNS spoof
protection feature that can be enabled through CLI
commands on the Sensor.
You can define a threshold value to limit the connection rate
or the number of active connections from each source. In
addition to this, you can also define rules to limit access
based on the connection rate, external hosts’ reputation and
geo-location.
UDP flood attacks can also be blocked by configuring the
“UDP Packet Volume too high” policy to block such attacks, in
both inbound and outbound traffic using the IPS Policy Editor.
Statistical anomaly is based on data learnt over a time
window. If performance with TCP is acceptable, use DNS
Protect, which is more deterministic. For immediate
prevention of connection based DoS attacks, Connection
Limiting would be more effective.
McAfee Network Security Platform 8.1
IPS Administration Guide
453
16
Denial-of-Service attacks
DoS attack prevention methods
Table 16-6 DoS attack prevention recommendations (continued)
Attack
Recommendation
Comments
UDP Flood
Connection Limiting
with McAfee GTI
Integration enabled
You can define a threshold value to limit the connection rate
or the number of active connections from each source. In
addition to this, you can also define rules to limit access
based on the connection rate, external hosts’ reputation and
geo-location.
Statistical Anomaly
Rate Limiting
UDP Flood attacks can be blocked by configuring the UDP
Packet Volume too high policy to block such attacks, in both
inbound and outbound traffic using the IPS Policy Editor.
Statistical anomaly is based on data learnt over a time
window. For immediate prevention of connection based DoS
attacks, Connection Limiting would be more effective.
Firewall access rules can be configured in the Manager to
block UDP traffic that is not expected to be seen with the
network.
ICMP Flood
Connection Limiting
with McAfee GTI
Integration enabled
Statistical Anomaly
Rate Limiting
You can define a threshold value to limit the connection rate
or the number of active connections from each source. In
addition to this, you can also define rules to limit access
based on the connection rate, external hosts’ reputation, and
geo-location.
ICMP Flood attacks can be blocked by configuring the ICMP
Packet Volume too high and ICMP Echo Request or Reply Volume too high
policies to block such attacks, in both inbound and outbound
traffic using the IPS Policy Editor.
Statistical anomaly is based on data learnt over a time
window. For immediate prevention of connection based DoS
attacks, Connection Limiting would be more effective.
Firewall access rules can be configured in the Manager to
block ICMP traffic that is not expected to be seen with the
network.
Non
TCP/UDP/
ICMP Flood
Statistical Anomaly
Non TCP/UDP/ICMP attacks can be blocked by configuring
the Non-TCP-UDP-ICMP Volume too high policy to block such attacks,
in both inbound and outbound traffic using the IPS Policy
Editor.
Exploit DoS
attacks
Network Security
Platform Signatures
Exploit attacks can be blocked by configuring policies to block
the exploit attacks (more than 3000) listed in the IPS Policy
Editor, for both inbound and outbound traffic.
Application
Level Flood
Custom Reconnaissance Use correlated attack definition, which is based on the
Attack Definition
individual attack definitions. For example, custom attacks
that check for URI can be further correlated to test for
multiple occurrences in a defined time interval to raise a
correlated attack.
Network Security Platform uses specific methods to prevent DoS attacks. These methods work
independently but can also be applied in combination.
Statistical anomaly
Network Security Platform uses binning to detect statistical anomalies and prevent DoS attacks.
The Sensor builds a profile for each tracked packet type in each direction. Within each source IP
profile, the entire IP address space is divided into a maximum of 128 mutually exclusive IP address
blocks, or bins, much in the same way CIDR addressing divides the address space. Each bin is
454
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack prevention methods
16
uniquely identified by a prefix and prefix length (from 2 to 32 bits). An IP address falls into a bin when
the first ‘n’ number of bits of the address matches the bin's prefix. The Sensor then associates each
source IP address with a particular bin in the appropriate profile.
Each bin has the following two properties:
•
The percentage of long-term good traffic originating from the source IP addresses that belongs to
this bin.
•
The percentage of the overall IP address space that the IP range in this bin occupies.
With the source IP addresses properly classified, the Sensor can protect a network from DoS attacks.
When a statistical anomaly occurs, the Sensor takes the following actions on the source IP profile in
question:
•
The Sensor blocks all packets with source IP addresses in the bins that occupy a large percentage
of the IP space, but represent a small percentage of the long-term traffic. This combats attacks
that are generated with random, wide-ranging, spoofed source IP addresses.
•
The Sensor blocks all packets with source IP addresses in the bins that occupy a large percentage
of the short-term traffic together with a significantly higher percentage of short-term traffic than
historically seen. This combats attacks that are initiated from a handful of networks with authentic
source IP addresses.
•
The Sensor does not block packets with source IP addresses in the bins that occupy a small
percentage of the IP space and represent a high percentage of the long-term traffic. This protects
against blocking hosts that are known to be good.
The exception to the third criterion is when the traffic also meets the second criterion. In other words,
source IP addresses from the good bins are blocked if their short-term traffic level is significantly
higher than their peak long-term level. This combats attacks that are initiated from good hosts that
have recently been compromised.
Source IP addresses classification is more effective than using devices such as firewalls that limits the
rate of SYN packets on the network to block DoS attacks. The key difference in such an approach and
Network Security Platform is that a rate-limiting device blocks traffic randomly. Good traffic has the
same probability of being blocked as attack traffic. On the other hand, source IP address classification
used by Network Security Platform attempts to differentiate good traffic from attack traffic, so attack
traffic is more likely to be blocked.
The statistical anomaly method is effective in preventing most attacks; however, there are some
chances of false positives.
Advanced malware botnet detection
Using the Advanced Malware policies, you can prevent DoS attacks that involve malware execution. An
Advanced Malware policy is a set of rules that scans the traffic across your network, and determines
how to respond to malware detected in the network. An effective policy is one that is customized to
the network environment being monitored.
To prevent DoS attacks through botnet, Network Security Platform provides heuristics based Advanced
Botnet Detection feature to protect customer networks from both known and 0‑day bots. This can be
enabled per VIDS for a Sensor. Enable the heuristics based Advanced Botnet Detection feature, which
detects bot activity by correlating multiple attacks across different flows. Attacks are correlated by
observing a host for a given period of time.
McAfee Network Security Platform 8.1
IPS Administration Guide
455
16
Denial-of-Service attacks
DoS attack prevention methods
In addition to what is explained above, malicious bot command and control servers' activity can be
detected. Detecting bot command and control server activity is a key feature of the Advanced Botnet
Detection. Network Security Platform monitors networks for bot attacks and protects the network by
updating the reputation of the newly identified bot masters in the cloud, using McAfee GTI.
For more information on Malware and Advanced Botnet Detection features, see the Advanced Malware
Detection chapter.
SYN cookie
In a SYN flood attack, server resources are targeted to consume TCP memory by sending SYN, and
after the server responds with a SYN+ACK, force the server to hold state information while waiting for
the Client’s ACK message. As the server maintains state for half-open connections, server resources
are constrained. The server might no longer be able to accept TCP connections, resulting in a DoS
condition.
Network Security Platform uses a specific choice of initial TCP number as a defense against SYN flood
attacks. The SYN cookie feature is a mechanism to counter SYN flood attacks. This feature is an
adjunct to the existing statistical anomaly-based DoS detection. In cases where a DoS attack is
already underway and there is no time for learning a long-term profile, Network Security Platform
provides the ability for the Sensor to proxy all inbound three-way handshakes.
With SYN cookies enabled in the Manager, whenever a new connection request arrives at a server, the
server sends back a SYN+ACK with an Initial Sequence Number (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. If the connection request is not from a
legitimate host, a TCP session is not created, and a potential DoS condition is prevented.
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. The
Manager provides an interface to the user to enable and disable the SYN cookie feature. It also
provides user the ability to configure the threshold values for the SYN cookies.
SYN cookies can be enabled for both inbound and outbound traffic.
•
Do not enable SYN cookies when passing MPLS traffic through a Sensor.
•
Sensors using SYN cookie settings must be in inline mode. If you don't have any ports in
inline mode, configure at least one port to be inline.
•
A Sensor will only see a packet once on any interface. However, if a Sensor is monitoring
an interface containing VLAN-tagged traffic, a separate subinterface must be configured
for each VLAN to ensure a packet is not seen more than once.
Stateful TCP engine
Sensor has a built-in TCP stack that follows the state required for TCP protocol. Sensor uses the TCP
state to prevent out of context packets and packets without a valid state. The TCP stateful engine can
be used effectively to drop spoofed TCP RST, TCP FIN, TCP ACK floods.
DNS protect
DNS protect feature in Sensor can be used to protect DNS servers from DoS spoof attack by forcing
the DNS clients to use TCP instead of UDP as their transport protocol. Since TCP uses
three-way-handshake, it is comparatively tough to launch spoofed attacks when TCP is used.
456
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
DoS attack prevention methods
16
You can set the DNS protection mode, add to, or delete existing DNS spoof protection IP addresses
from the protected server list using CLI commands.
set dnsprotect
This command, when executed, sets the DNS protection mode.
Syntax
set dnsprotect <inbound/inbound-outbound/ip-based/off/outbound>
Parameter
Description
<inbound>
sets the DNS protection mode to 'inbound'
<inbound-outbound>
sets the DNS protection mode to 'inbound-outbound'
<ip-based>
sets the DNS protection mode to 'ip-based'
<off>
turns off the DNS protection mode
<outbound>
sets the DNS protection mode to 'outbound'
The list of protected destination IP addresses can be edited irrespective of this setting.
dnsprotect
This command, when executed, performs the following tasks:
•
Adds new DNS Spoof protection IP address.
•
Deletes existing DNS Spoof protection IP addresses (IPv4, IPv6 or both) from the Protected Server
List (PSL).
•
Re-lists the DNS spoofing protection IP address.
Syntax:
dnsprotect <add/delete/> <ipv4/ipv6> <IP address>
While using the <resetlist> parameter, use the following syntax: dnsprotect <resetlist> <ipv4/
ipv6/all>
Parameter Description
add
Adds a new DNS spoofing protection IP address
delete
Deletes an existing DNS spoofing protection IP address
resetlist
Resets the list the DNS spoofing protection IP address
ipv4
Indicates that the IP address is for ipv4 packet
ipv6
Indicates that the IP address is for ipv6 packet
all
Indicates that the resetlist of the existing DNS spoofing protection IP address is for both
ipv4 and ipv6.
Example:
The following example shows the dnsprotect command used for adding the DNS Spoof protection IP
address for ipv4.
dnsprotect add ipv4 157.125.202.255.
The following example shows the dnsprotect command used for reset listing of DNS Spoof protection
IP address for all the IP addresses (ipv4 and ipv6).
McAfee Network Security Platform 8.1
IPS Administration Guide
457
16
Denial-of-Service attacks
DoS attack prevention methods
dnsprotect resetlist all
This command does not perform on IPv6 packets that have a routing header.
Rate Limiting
You can use the Rate Limiting feature to control the rate of egress traffic sent through the ports of a
Sensor. When deployed in inline mode, Sensor permits rate limiting of traffic by limiting the bandwidth
of the traffic that goes through the Sensor ports. Traffic that is less than or equal to the specified
bandwidth value is allowed, whereas traffic that exceeds the bandwidth value is dropped. The Sensor
uses the token bucket approach for rate limiting traffic. An administrator can set appropriate values in
the Manager to prevent DoS by setting Sensor port specific bandwidth limits that are relevant for
preventing DoS in a particular network. The Rate Limiting feature is available as part of the Quality of
Service (QoS) policies.
You can rate-limit by protocol such as P2P, HTTP and ICMP as by TCP ports, UDP ports, IP protocol
number, and various other parameters including applications, Windows Active Directory user name,
geographical location. For more details see the Quality of Service chapter.
Network Security Platform provides rate limiting configuration at individual sensor ports. For example,
if 1A-1B is a port-pair, QoS policy is configured separately for 1A and 1B. QoS policy for a port applies
to egress traffic only.
Rate limiting is very effective when applied in a specific context with full knowledge of the nature of
traffic in a particular network. Rate limiting needs to be applied carefully as it might drop legitimate
traffic as well.
Firewall policies
You can use Firewall policies to prevent DoS attacks.
A Firewall policy consists of ordered rules for permitting and denying traffic from reaching a Sensor's
inspection engine and continuing on through the network. Firewall policies complement IPS policies
and exception objects to help tune a deployment. You can use Firewall policies with a Sensor in inline
mode to drop or deny traffic from or to specific hosts or within a range of hosts, or traffic that meets
particular requirements such as protocol type, port, application, and Windows Active Directory
credentials.
Firewall policies can be created for a combination of any source IP addresses, destination IP
addresses, specified CIDR blocks, destination protocol/port, by TCP/UDP port, by ICMP type, and by IP
protocol for the Sensor as a whole and per individual port pair.
Firewall policies can be used to mitigate DoS attacks by creating policies specific to the nature of
traffic in a network. For instance, if you are aware of what protocols are normally seen in your
network, you can configure Firewall policies to drop the type of traffic that is not normally expected in
your network.
Scan, Drop, Deny, or Ignore response action can be set while enabling intrusion prevention matching a
configured rule. When used within an enterprise, Scan can be configured from all known CIDRs.
Connection limiting with McAfee GTI integration enabled
You can define a threshold value to limit the number of connections per second or the number of
active connections to prevent connection based DoS attacks.
458
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Managing DoS-related actions using command line interface
16
The Sensor provides the ability to define threshold values to limit number of connections (three-way
TCP handshakes) a host can establish. The number of connections or connection rate that is less than
or equal to the defined threshold value is allowed. When this number is exceeded, the subsequent
connections are dropped. This helps in minimizing the connection-based DoS attacks on server.
The threshold value is defined as the number of connections/second or active connections. For
example, if you define 1 connection per second as the threshold value then, there are 10 connections
in the first second, all the other connections from the second to the tenth second will be dropped. On
the other hand, if you have 1 connection for each second, all the 10 connections until the tenth second
will be allowed. This is also known as traffic sampling.
You can define the Connection Limiting rules of the following types:
•
Protocol — use this to limit TCP/UDP/ICMP active connections or connection rate from a host.
•
GTI — In this case, the Sensor integrates with McAfee GTI IP Reputation to obtain the reputation
score and geo-location of the external host. Therefore, use this to define Connection Limiting rules
for traffic to and from external hosts based on reputation and geo-location of the external hosts.
Custom Reconnaissance Attack Definition
You can create custom signature-based attack definitions to prevent exploit based DoS attacks. Using
the Custom Attack Editor, you can define correlated attacks using these individual attack definitions.
For example, Custom Attacks that check for URI can be further correlated to test for multiple
occurrences in a defined time interval to raise a correlated attack. The correlation methods supported
are:
•
Brute force
•
Service sweep
•
Host sweep
•
Fingerprinting
•
Port scan
When traffic passing through the Sensor exceeds the threshold count set for the Custom
Reconnaissance Attack within a configured Interval, the Sensor raises an alert to the Manager. You can
then opt to take the response actions such as blocking or quarantining the host.
See also
Reconnaissance policies management on page 491
Managing DoS-related actions using command line interface
You can use Network Security Platform command line interface (CLI) commands in conjunction with
the options available in the Manager to set DoS prevention severity, block DoS traffic, and to protect
against DNS spoof attacks.
The following CLI commands can be used to view information on profiles and severity:
•
show dospreventionprofile — Displays the specified denial of service profile information for the
Sensor. This is defined in two arguments—a DoS measure name and traffic direction.
•
show dospreventionseverity — Displays the severity for a specified DoS profile.
McAfee Network Security Platform 8.1
IPS Administration Guide
459
16
Denial-of-Service attacks
Managing DoS-related actions using command line interface
Set Denial-of-Service prevention severity
The set dospreventionseverity command, when executed, sets severity for the specified DoS
measure. Increasing the DoS prevention severity increases the number of DoS packets dropped. The
default value is 30. The largest value is 200, and the smallest is 0.
Syntax
set dospreventionseverity <dos-measure-name> <inbound | outbound> <0-200>
Takes two arguments:
•
A DoS measure name: one of 'tcp-syn', 'tcp-syn-ack', 'tcp-fin', 'tcp-rst', 'udp', 'icmp-echo',
'icmp-echo-reply', 'icmp-non-echo-reply', 'ip-fragment', and 'non-tcp-udp-icmp'
•
A direction (one of 'inbound' or 'outbound')
For example, set dospreventionseverity tcp-syn-ack outbound 100
Block DoS attack traffic from a specific host
This section provides the high-level steps, with examples, on how to block a host that is launching a
DoS attack.
Task
1
Keep the inline Sensor in learning mode for 48 hours so that normal traffic pattern is learnt.
2
Send some particular type of traffic from selected IP addresses through the Sensor during the
learning mode, that is, for the first 48 hours.
For example, send 5 Mbps of UDP packet type to the Sensor from selected IP address such as,
10.10.0.1, 198.19.0.2, 120.100.10.1, 100.10.10.11 and 99.40.10.30.
The Sensor automatically switches to detection mode after the first 48 hours.
3
Enable blocking for the corresponding attack in the DoS policy.
For example, enable blocking for Inbound UDP Packet Volume Too High attack definition in the DoS policy.
4
Set the maximum value on the Sensor using the CLI command — set dospreventionseverity
<packet type> <direction> <value>
5
Send significantly more similar traffic from the selected IP address through the Sensor than what
was sent during the learning mode.
For example, send more than 50 Mbps traffic from the IP address 10.10.0.1. Now, the traffic from
the IP address 10.10.0.1 is blocked.
Viewing a DoS profile
The show dospreventionprofile command, when executed, displays the specified DoS prevention
profile information for the Sensor, defined in two arguments — a DoS measure name and a traffic
direction.
Syntax:
show dospreventionprofile <dos-measure-name> <inbound | outbound>
460
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Managing DoS-related actions using command line interface
Parameter
16
Description
<dos-measure-name> Indicates the DoS measure name — one of tcp-syn, tcp-syn-ack, tcp-fin,
tcp-rst, udp, icmp-echo, icmp-echo-reply, icmp-non-echo-reply,
ip-fragment, or non-tcp-udp-icmp.
<direction>
Indicates the direction. It can be inbound or outbound.
Example - Command execution:
show dospreventionprofile udp inbound
Information displayed by the show dospreventionprofile command includes the Sensor's DoS
profile and the traffic direction protected by the profile.
Example - Result:
show dospreventionprofile udp inbound
packet type: UDP IN (12), profile stage: normal operation (65)
long-term average rate=0.000(pkts/s), last_rate=0.000(pkts/s)
no attack in progress
each line: bin_index, IP_prefix/prefix_len, AS, LT, ST, ltR(ate), stR(ate)
AS(%) -- percentage of the IP address space this bin occupies
LT(%) -- percentage of long-term traffic that falls into this bin
ST(%) -- percentage of short-term traffic that falls into this bin
ltRate -- long-term average traffic rate (in pkts/s) for this bin
stRate -- short-term traffic rate (in pkts/s) for this bin
0: 0.0.0.0/2 AS=25.000% LT=25.000% ST=25.00% ltR=0.000 stR=0.000
1: 128.0.0.0/2 AS=25.000% LT=25.000% ST=25.00% ltR=0.000 stR=0.000
2: 64.0.0.0/2 AS=25.000% LT=25.000% ST=25.00% ltR=0.000 stR=0.000
3: 192.0.0.0/2 AS=25.000% LT=25.000% ST=25.00% ltR=0.000 stR=0.000
McAfee Network Security Platform 8.1
IPS Administration Guide
461
16
Denial-of-Service attacks
Connection Limiting policies
The following is an example of a "bad" bin marked with a "*". The Sensor blocks packets with source
IPs in the particular bin.
0: 0.0.0.0/6 AS=1.563% LT=49.969% ST=100.00% stR=1.000
1: 128.0.0.0/2 AS=25.000% LT=0.021% ST=0.00% stR=0.000
*2: 64.0.0.0/2 AS=25.000% LT=1.615% ST=100.00% ltR=2357.098 stR=148966.400
3: 192.0.0.0/2 AS=25.000% LT=0.021% ST=0.00% stR=0.000
4: 32.0.0.0/3 AS=12.500% LT=0.000% ST=0.00% stR=0.000
5: 16.0.0.0/4 AS=6.250% LT=0.000% ST=0.00% stR=0.000
6: 8.0.0.0/5 AS=3.125% LT=0.000% ST=0.00% stR=0.000
7: 4.0.0.0/6 AS=0.000% LT=11.752% ST=0.00% ltR=16885.654 stR=0.000
Viewing DoS prevention severity
The show dosPreventionseverity command, when executed, displays the severity for a specified
denial of service profile.
Syntax
show dosPreventionseverity <dos-measure-name> <inbound | outbound>
Parameter
Description
<dos-measure-name> Indicates the DoS measure name — one of tcp-syn, tcp-syn-ack, tcp-fin,
tcp-rst, udp, icmp-echo, icmp-echo-reply, icmp-non-echo-reply,
ip-fragment, or non-tcp-udp-icmp.
<direction>
Indicates the direction. It can be inbound or outbound.
Example - Command execution
show dospreventionseverity tcp-syn-ack outbound
Example - Result
DOS Prevention Severity for tcp-syn-ack outbound is 30
Connection Limiting policies
Connection Limiting policies consist of a set of rules that enable the Sensors to limit the number of
connections a host can establish or a connection rate.
The Sensor provides the ability to define threshold values to limit number of connections (three-way
handshakes for TCP) a host can establish. The number of connections or the connection rate that is
less than or equal to the defined threshold value is allowed, whereas the same exceeding the value is
dropped. This helps in minimizing connection-based DoS attacks on your network.
462
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
The integration of this technology with McAfee GTI IP Reputation helps to define the connection
limiting rules for traffic to and from external hosts based on reputation and geographical-location of
the external hosts. These defined Connection Limiting policies can also be assigned at the interface
and subinterface levels.
Examples:
•
When 100 active HTTP connections are limited from a single source, subsequent connections are
dropped.
•
When 500 active overall connections (all TCP and UDP) are limited from a single source,
subsequent connections are dropped.
•
When 200 DNS requests per second are limited from a single source, subsequent connections
within this time interval are dropped.
M-series Sensors provide capability to limit the number of connections a host can establish or a
connection rate.
The policy specifies connection rules of following two types:
•
McAfee GTI based to limit connection rate based on reputation and/or geo location of external
hosts.
•
Protocol based to limit TCP/UDP/ICMP connections or connection rate from a host.
Both the above-mentioned rules are specified on a per direction basis. The connection policy is
assigned to interface or subinterface level. McAfee GTI-based rules are only applicable when IP
Reputation is enabled on the interface or subinterface level. They query the IP Reputation server to
get reputation and geographical location of the external host.
In case of McAfee GTI-based rules, connection limiting is applicable only to IPv4 traffic. Protocol-based
rules are applicable for both IPv4 and IPv6 traffics.
How Connection Limiting policies work
You can create the Connection Limiting policy at the admin domain level. You can configure the
Connection Limiting policy with the monitoring ports in SPAN, tap, or inline modes.
The response actions differ for SPAN and tap modes. In these modes, the Sensor cannot block the
connections or quarantine the hosts.
The connections are limited based on the predefined threshold value. The threshold value is defined as
connections per second or active connections. For example, if you define 1 connection per second as
the threshold value, then, 10 connections are allowed per 10 seconds. So, if there are 10 connections
in the first second, all the other connections from the second to the tenth second are dropped. On the
other hand, if you have 1 connection for each second, all the 10 connections until the tenth second are
allowed. This is also known as traffic sampling.
The minimum and maximum threshold values are 1 connection per second and 65535 connections per
second respectively.
After you create a Connection Limiting policy, you can assign it to a Sensor's interfaces and
subinterfaces.
These Sensor resources must be of type VLAN or CIDR. You can assign the policy to these levels
depending upon the configuration of the monitoring ports.
McAfee Network Security Platform 8.1
IPS Administration Guide
463
16
Denial-of-Service attacks
Connection Limiting policies
After you assign the Connection Limiting policy, the Sensor limits the connections based on the
configured threshold values. An alert is sent each time the connection exceeds the defined threshold
value. You can have any of the following response actions for that connection:
•
Alert only
•
Alert and drop excess connections
•
Alert and deny excess connections
•
Alert and quarantine
The Connection Limiting policies work differently for different Sensor models. Although the threshold
value determines the number of connections to be limited, the traffic is load-balanced in case of higher
M-series Sensor models, which have multiple processors. For example, in case of M-1250 through
M-3050 Sensors, if you define a threshold value of 5 connections per second for the HTTP traffic, then
50 connections are limited in 10 seconds. For M-8000 Sensors, this will be load-balanced to handle the
connections across multiple processors. There can be a slight variation in the exact connections limited
by the Sensors based on the traffic handled by each at any given time.
Considerations for Connection Limiting policies
Consider the following when you use Connection Limiting policies:
•
Threshold values defined in any rule are based on the source IP address.
•
A maximum of 1024 rules can be defined for each Sensor.
•
Traffic sample time for the connection rate monitoring is 10 seconds. This means if you define 5
connections per second, then, 50 connections are limited in 10 seconds. So, an alert will only be
raised if you send more than 50 connections in 10 seconds.
•
In a fail-over setup, each Sensor monitors the traffic based on its own system time. As the system
time for each Sensor differs, the time each Sensor samples a traffic might not be exactly same.
This can result in a mismatch of the connection limiting response actions for each Sensor.
•
Each Sensor model has a limitation of a maximum number of new hosts that it can handle per
second. When the new host rate exceeds this value, the connections are not limited by the Sensor.
•
Protocol based connection limiting rule type applies to both IPv4 and IPv6 traffic. McAfee GTI does
not support IPv6 traffic, so GTI-based connection limiting rule type applies to IPv4 traffic only.
•
Connection Limiting rules can be applied to SPAN ports. If CIDRs are not defined for the SPAN port,
inbound connection limiting rules are applied to all traffic on SPAN port. If CIDR is defined for the
SPAN port, the traffic to the CIDR is treated as inbound traffic and traffic from the CIDR is treated
as outbound traffic.
•
McAfee GTI IP Reputation has to be enabled for McAfee GTI rule type.
•
Connection Limiting is applicable for stateless inspection.
The following table shows the maximum host entries supported for different Sensor models.
464
Sensor model
Maximum host entries
supported
M-2750, M-2850, M-2950, M-3030, M-3050, M-4030, M-4050,
M-6030, M-6050, M-8030, M-8000
256,000
M-1250 and M-1450
128,000
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
Components of Connection Limiting rules
You define Connection Limiting rules in a Connection Limiting policy. To effectively use Connection
Limiting policies, familiarize yourself with the components that make up a Connection Limiting rule.
Figure 16-28
Connection Limiting rules options
Table 16-7 Connection Limiting rules option definitions
Option
Definition
#
Displays the serial number of the rule. This is referenced in the alerts.
State
Displays whether a rule is enabled or disabled. Sensor does not apply disabled rules.
This option might help you during troubleshooting.
Description
Optionally enter additional information about the rule. You can enter a description up to
64 characters long and click OK.
Direction
• Inbound — To apply this rule only to traffic seen at the outside port.
• Outbound — To apply this rule only to traffic seen at the inside port.
• Any — To apply this rule at both the ports.
Rule Type
• Protocol — To limit TCP/UDP/ICMP active connections or connection rate from a host.
• GTI — To limit connection rate based on reputation and/or geo-location of external
hosts.
McAfee GTI-based rules are only applicable when McAfee GTI IP Reputation is enabled.
Both the rule types are specified on a per-direction (inbound/outbound) basis.
Threshold
Type :
• Connection Rate — The rate of the connection defined per second.
• Active Connections — The number of active connections.
Only Connection Rate is available for McAfee GTI rules.
McAfee Network Security Platform 8.1
IPS Administration Guide
465
16
Denial-of-Service attacks
Connection Limiting policies
Table 16-7 Connection Limiting rules option definitions (continued)
Option
Definition
Value: Define the connections per second or the number of active connections based on
the threshold type you selected.
External
Reputation : Select one of the external McAfee GTI reputations (risk levels):
• High Risk
• Medium Risk or High Risk
• Unverified, Medium or High Risk
• Any
This option is applicable only for McAfee GTI rule type.
Location : Select the external geo-location (McAfee GTI countries).
This option is applicable only for McAfee GTI rule type.
Service
Select one of the following transport protocols from the Transport Protocol drop-down list:
• TCP (You can specify the port number for TCP protocol.)
• UDP (You can specify the port number for UDP protocol.)
• Ping (ICMP echo Request)
• All TCP & UDP
Figure 16-29 Service option
Service component is only applicable for protocol rule type.
Response
Select the response action that the Sensor must perform when the traffic matches the
options you specified in the Connection Limiting rule. The following are the response
options:
• Alert Only
• Alert & Drop Excess Connection
• Alert & Deny Excess Connection
• Alert & Quarantine
Prompt for
assignment
after save
When selected, the Assignments window opens when you save a policy and you can
assign the policy to the required Sensor resources. When deselected, the rule is saved
in the Manager database and the policy appears in the Connection Limiting Policies list.
Save
Saves the Connection Limiting rules in the Manager database. The Connection Limiting
policy is listed in the Connection Limiting Policies list.
Comparison between Protocol and McAfee GTI rule type
The following table shows the comparison between the two rule types.
466
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
Table 16-8 Protocol and McAfee GTI rule types - comparison
Rule components Protocol rule type
McAfee GTI rule type
Description
Applicable
Applicable
Direction
Applicable
Applicable
Threshold Type
Both the threshold types are applicable Only Connection Rate threshold type is
applicable
Threshold
Applicable
Applicable
External Reputation Not applicable
Applicable
External Location
Not applicable
Applicable
Service
Applicable
Not applicable
Response
Applicable
Applicable
Considerations for rule types
Follow these considerations for the rule types.
•
•
For Protocol rule type:
•
In one policy, for one direction, only one All TCP/UDP connection rate rule can be defined.
•
In one policy, for one direction, only one All TCP/UDP active connection rule can be defined.
For McAfee GTI rule type:
•
For McAfee GTI connection rate rule, geo-location and risk level should not be "any" at the same
time.
•
For McAfee GTI connection rate rule, defined risk level means the selected risk level and above.
For example, medium risk rules can be applied to high risk traffic if no high risk rule is defined.
•
For one specific geolocation, user can only create two McAfee GTI rules:
•
One McAfee GTI rule with a specific reputation level (high risk, medium risk, unverified,
minimal risk) defined: this rule will apply to the traffic for this geo-location has the
reputation same or worse than the defined level. The level defined in this rule can be taken
as the malicious cut off level for this geo-location.
•
One McAfee GTI rule with ANY reputation: this rule will apply to ANY traffic for this
geo-location (including all reputation levels and even for the traffic that has no reputation
information available). This rule is only based on geo-location and can work even without
McAfee GTI enabled (as long as the geo-location database is pushed to the Sensor).
•
For McAfee GTI connection rate rule, for outbound direction, "Quarantine" response action is not
applicable.
•
When different rule types affect same traffic, the action is taken for the threshold hitting first.
The rule applying order is as follows:
Proto-conn-rate-rule->proto-active-conn rule -> all TCP/UDP conn-rate-rule->all TCP/UDP
active-conn-rule->geoLocation specific reputation GTI-conn-rate-rule->geoLocation specific Any
reputation GTI-conn-rate-rule->Any geoLocation reputation specific GTI_conn_rate_rule
•
No McAfee GTI rules apply to whitelisted hosts.
•
When McAfee GTI is enabled and Connection Limiting rules are configured, you can block the
malicious traffic received on the inbound connections. For example, you can deploy a Sensor in
front of a web server, and enable McAfee GTI along with Connection Limiting rules to limit
access to the server and prevent DoS attacks.
McAfee Network Security Platform 8.1
IPS Administration Guide
467
16
Denial-of-Service attacks
Connection Limiting policies
Effects of X-Forwarded-For (XFF) on connection limiting
Review this section to know how the Sensor implements Connection Limiting policies if you have
enabled XFF.
Effect on HTTP traffic when XFF is enabled
When XFF is enabled, it is assumed that all HTTP traffics on that VIDS level are XFF traffic. No
connection limiting is done if the traffic is non-XFF when XFF is enabled.
Sensor checks the XFF traffic against protocol-based rules. When the connections exceed the threshold
value, a response action is triggered. An alert can be raised or the connection can be blocked based on
the configuration.
This works irrespective of syn cookie setting. Quarantine response is not supported for XFF traffic.
Effect on HTTPS traffic when XFF is enabled
When SSL is disabled, the Sensor handles the connection limiting for HTTPS traffic based on the
source IP address. It is not dependent on whether XFF is enabled or not.
When SSL is enabled, and if the Sensor cannot decrypt the traffic (no server certificate on Sensor), no
connection limiting takes place for XFF and non-XFF HTTPS traffic.
When SSL is enabled, and if the Sensor can decrypt the traffic (Sensor has server certificate), no
connection limiting takes place for non-XFF https traffic.
The behavior of connection limiting is same for XFF HTTPS and HTTP traffics.
Effect of non-standard port on HTTP/HTTPS traffic
By default, XFF connection limiting is only performed for HTTP/HTTPS traffic on standard port. If the
HTTP/HTTPS traffic runs on non-standard port, you must define the non-standard port on Manager.
Effect of XFF IP address on an alert
An XFF IP address can be IPv4 or IPv6 irrespective of the proxy IP address (it can also be ipv4 or
ipv6). Connection limiting is only based on XFF IP address and not the proxy IP address.
McAfee GTI does not support XFF IP address, so no McAfee GTI rule types are applied to XFF traffic.
If both XFF and connection limiting are enabled, no connection limiting processing will be done for
normal non-XFF https traffic.
Create, clone, and modify Connection Limiting policies
You can create and manage Connection Limiting policies at an admin-domain level. After you create
the Connection Limiting policies for an admin domain, you can assign it to the corresponding Sensor
interfaces and sub-interfaces.
Task
468
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
3
16
Select Intrusion Prevention | Connection Limiting Policies.
Figure 16-30 Connection Limiting policies page
4
Click New to create a new policy.
The Properties tab displays.
McAfee Network Security Platform 8.1
IPS Administration Guide
469
16
Denial-of-Service attacks
Connection Limiting policies
5
Specify the details in the Properties tab.
Figure 16-31 Properties tab
Table 16-9 Properties option definitions
Option
Definition
Name
Enter a unique name to easily identify the policy.
Description
Optionally describe the policy for other users to identify its purpose.
Owner
Displays the admin domain to which the policy belongs.
Visibility
Select Owner domain only to make the policy available only to the owner domain
or select Owner and child domains to makes the policy available to the
corresponding child admin domains.
However, the policy cannot be edited or deleted from the child admin domains.
Editable here
The status Yes indicates that the policy is owned by the current admin domain.
Statistics
Lasted Updated : Displays the time stamp when the policy was last modified.
Last Updated By : Displays the user who last modified the policy.
Assignments of this policy: Indicates the number of interfaces and sub-interfaces to
which the policy is assigned.
Inbound Connection Limiting Rules: Displays the number of Connection Limiting rules
currently defined for inbound traffic.
Outbound Connection Limiting Rules: Displays the number of Connection Limiting
rules currently defined for outbound traffic.
Prompt for assignment When selected, you are automatically prompted to select the Sensor resources
after save
to which you want to assign the policy.
Save
470
Saves the changes made in the Properties tab. This is visible only when you
open an existing policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
Table 16-9 Properties option definitions (continued)
6
Option
Definition
Next
Saves the changes made in the Properties tab and to access the Connection Limiting
Rules tabbed region. This button is available only when you create a policy.
Cancel
Reverts to the last saved configuration.
In the Connection Limiting Rules, click the appropriate button to insert a new rule.
Table 16-10 Connection Limiting rule button definitions
Button
Definition
Inserts a new rule above the currently selected rule.
Inserts a new rule below the currently selected rule.
Clones the currently selected rule.
Deletes the currently selected rule.
Moves the currently selected rule one row up.
Moves the currently selected rule one row down.
7
Double-click each column of a Connection Limiting rule and specify your choices.
Figure 16-32
Connection Limiting rules options
Table 16-11 Connection Limiting rules option definitions
Option
Definition
#
Displays the serial number of the rule. This is referenced in the alerts.
Enabled
Displays whether a rule is enabled or disabled. Sensor does not apply disabled rules.
This option might help you during troubleshooting.
McAfee Network Security Platform 8.1
IPS Administration Guide
471
16
Denial-of-Service attacks
Connection Limiting policies
Table 16-11 Connection Limiting rules option definitions (continued)
Option
Definition
Description
Optionally enter additional information about the rule. You can enter a description up
to 64 characters long and click OK.
Direction
• Inbound — To apply this rule only to traffic seen at the outside port.
• Outbound — To apply this rule only to traffic seen at the inside port.
• Either — To apply this rule at both the ports.
Rule Type
• Protocol — To limit TCP/UDP/ICMP active connections or connection rate from a
host.
• GTI — To limit connection rate based on reputation and/or geo-location of external
hosts.
McAfee GTI-based rules are only applicable when McAfee GTI IP Reputation is
enabled.
Both the rule types are specified on a per-direction (inbound/outbound) basis.
Threshold
Type:
• Connection Rate — The rate of the connection defined per second.
• Active Connections — The number of active connections.
Only Connection Rate is available for McAfee GTI rules.
Value : Define the connections per second or the number of active connections based
on the Threshold Type you selected.
External
Reputation: Select one of the external McAfee GTI reputations (risk levels):
• High Risk
• Medium Risk or High Risk
• Unverified, Medium or High Risk
• Any
This option is applicable only for McAfee GTI rule type.
Location : Select the external geo-location (McAfee GTI countries).
This option is applicable only for McAfee GTI rule type.
472
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
Table 16-11 Connection Limiting rules option definitions (continued)
Option
Definition
Service
Select a protocol from the Transport Protocol drop-down list:
• TCP (You can specify the port number for TCP protocol.)
• UDP (You can specify the port number for UDP protocol.)
• Ping (ICMP echo Request)
• All TCP and UDP
Figure 16-33 Service option
Service component is only applicable for protocol rule type.
Response
Select the response action that the Sensor must perform when the traffic matches
the options you specified in the Connection Limiting rule.
Prompt for
assignment
after save
When selected, the Assignments window opens when you save a policy and you can
assign the policy to the required Sensor resources. When deselected, the rule is
saved in the Manager database and the policy appears in the Connection Limiting Policies
list.
Save
Saves the Connection Limiting rules in the Manager database. The Connection
Limiting policy is listed in the Connection Limiting Policies list.
Assign a Connection Limiting policy to an interface or
subinterface
After you define a Connection Limiting policy at the admin domain, you can assign it to an interface or
subinterface.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select IPS Interfaces | <interface-x name> | <sub-interface-x name> | Protection Profile | Connection Limiting Policy.
Figure 16-34 Connection Limiting Policy area in IPS Interface tab
6
Select the Assign a Connection Limiting Policy? checkbox.
McAfee Network Security Platform 8.1
IPS Administration Guide
473
16
Denial-of-Service attacks
Connection Limiting policies
7
Select the required Connection Limiting policy and click Save.
8
Deploy the configuration changes to the Sensor.
Alert for Connection Limiting policies
You can define the threshold values while creating rules in a Connection Limiting policy. When the
Sensor monitors a traffic and the connection exceeds the configured threshold value, the connection is
limited and an alert is raised. You can set any of the following response actions:
•
Alert only
•
Alert and drop excess connection
•
Alert and deny excess connection
•
Alert and quarantine
There is only one reconnaissance alert defined for the Connection Limiting feature: "Too Many
TCP/UDP/ICMP Sessions." You can view the alert in the All Alerts page of the Real-Time Threat Analyzer.
Double-click the alert to view the alert details.
Figure 16-35 Connection Limiting alert
474
McAfee Network Security Platform 8.1
IPS Administration Guide
Denial-of-Service attacks
Connection Limiting policies
16
Scenario
Same host triggering the same rule:
In this scenario, no alert will be sent to the Threat Analyzer during the alert timeout interval. So, when
a traffic is sent to the Sensor, you can see the alert only after 5 minutes the first alert is triggered.
This condition is not true for the Connection Limiting alerts for different hosts or different rules.
By default the alert timeout interval is 5 minutes. You can edit the alert timeout from the Reconnaissance
Policy Editor.
Exceed connection count
Exceed Connection Count is displayed by the Connection Limiting alert when the response action is Alert Only.
Sensor sends out Connection Limiting alert as soon as the pre-defined threshold value is reached. So,
the first alert always shows Exceed Connection Count as 1. If the traffic continues and triggers another
alert after the alert timeout interval (with same connection limiting policy), then the Exceed Connection
Count displayed in the next alert equals to the exceed connection count that the Sensor monitors
between these two alert time intervals.
If the traffic does not continue long enough to reach the next alert time interval, another Connection
Limiting alert will not be triggered. In this case, evenif the connection exceeds the configured
threshold value, the connection will not be limited.
Connection Limiting Host Entries Exhausted alert
The connection is limited based on the threshold defined but no alerts are sent.
CLI commands
The following CLI commands are used for the debugging purpose for Connection Limiting policy.
•
show connlimitstat - show connection limiting statistics
•
show connlimithost - shows connection limiting host table stats
•
clrconnlimithost - clears connection limiting host table
Refer McAfee Network Security Platform CLI Guide for more details.
McAfee Network Security Platform 8.1
IPS Administration Guide
475
16
Denial-of-Service attacks
Connection Limiting policies
476
McAfee Network Security Platform 8.1
IPS Administration Guide
17
Inspection of SSL traffic
A disadvantage often cited for NIPS is the inability to inspect and analyze encrypted traffic. Encrypted
traffic prevents nearly all NIPS from inspecting the packets for attacks or other unauthorized activity.
Sensors, however, are equipped to decrypt Secure Socket Layer (SSL) packets for inspection and
response in cases of attack.
Network Security Platform 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 Manager client, you download your SSL keys to a Sensor. The Sensor keeps the
server key in volatile memory after receiving it from the Manager. The key is stored in 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 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.
Network Security Platform supports the PKCS12 format—file suffixes ".pkcs12", ".p12", or ".pfx"—with
an RSA private key no longer than 2048 bits. The keys work across all of a Sensor's Virtual IPS (VIPS)
instances. The private key must be a part of the PKCS12 file.
There is a performance impact when using the SSL decryption feature. SSL decryption is not supported
by I-1200, I-1400, M-1250, and M-1450 Sensors. I-series Sensors (other than I-1200 and I-1400) can
support up to 64 SSL certificates. M-series Sensors (other than M-1250 and M-1450) can support up to
256 SSL certificates.
Contents
Supported web servers and cipher suites for SSL inspection
Unsupported SSL functionalities
Steps involved in configuring SSL decryption
SSL best practices
Supported web servers and cipher suites for SSL inspection
SSL decryption is supported for the following web servers:
•
Microsoft Internet Information Server (IIS)
•
Apache
•
IBM WebSphere
McAfee Network Security Platform 8.1
IPS Administration Guide
477
17
Inspection of SSL traffic
Unsupported SSL functionalities
The following SSL cipher suites (as named in their respective RFCs) are supported:
SSLv2 cipher suites
•
SSL_CK_RC4_128_WITH_MD5
•
SSL_CK_RC4_128_EXPORT40_WITH_MD5
•
SSL_CK_DES_64_CBC_WITH_MD5
•
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
SSLv3/TLS cipher suites
•
SSL/TLS_NULL_WITH_NULL_NULL
•
SSL/TLS_RSA_WITH_DES_CBC_SHA
•
SSL/TLS_RSA_WITH_NULL_MD5
•
SSL/TLS_RSA_WITH_3DES_EDE_CBC_SHA
•
SSL/TLS_RSA_WITH_NULL_SHA
•
SSL/TLS_RSA_WITH_AES_128_CBC_SHA
•
SSL/TLS_RSA_WITH_RC4_128_MD5
•
SSL/TLS_RSA_WITH_AES_256_CBC_SHA
•
SSL/TLS_RSA_WITH_RC4_128_SHA
Unsupported SSL functionalities
The following SSL functionalities are not supported:
•
iPlanet Web servers
•
Diffie-Hellman ciphers (McAfee recommends that you disable acceptance of Diffie-Hellman requests
on the SSL Web server to ensure that Network Security Platform is able to decrypt the traffic)
•
Compression in the SSL records (a negotiable option in SSLv3 and TLS)
•
PCT (Microsoft's extension to SSLv2)
Steps involved in configuring SSL decryption
At a high-level the following are the steps to configure a Sensor to decrypt and inspect SSL traffic:
1
Enable SSL decryption on the required Sensors and configure Sensor SSL parameters.
2
Import the private SSL certificates of the corresponding web servers into the Manager. The Sensors
subsequently download these certificates from the Manager.
Various fault messages are raised in the Manager related to SSL decryption. For example, an imported
SSL certificate might have become invalid or you might have modified SSL configuration settings that
require a Sensor reboot. All these fault messages are explained in detail in the Network Security
Platform Troubleshooting Guide.
478
McAfee Network Security Platform 8.1
IPS Administration Guide
Inspection of SSL traffic
Steps involved in configuring SSL decryption
17
Enable SSL decryption on a Sensor
SSL configuration includes enabling SSL decryption, enabling packet logging for SSL-encrypted
attacks, setting the number of SSL flows to monitor simultaneously, and setting the session cache
time. By default, a Sensor decrypts SSL traffic only on TCP port 443. To decrypt SSL on a
non-standard port, make sure you have defined the non-standard port for HTTP with SSL enabled. To
do this, select the device and go to Policy | Advanced | Non-Standard Ports.
If you enable or disable SSL decryption on a Sensor or modify the count of SSL flows, you must reboot
the Sensor for the changes to take effect. You opt for a Hitless or a Full Reboot.
The number of supported SSL flows on a Sensor directly impacts the number of TCP flows that can be
processed simultaneously by a 2-to-1 ratio. For example, an I-4000 Sensor can maintain 1,000,000
TCP flows. When you set the number of SSL Flows to 100,000 (the maximum), that value reduces the
number of TCP flows monitored by an I-4000 to 800,000 flows.
SSL decryption is not supported on I-1200, I-1400, M-1250, and M-1450 Sensors.
Task
1
Click the Devices tab.
2
Select the domain from the Domain drop-down list.
3
In the left pane, click the Devices tab.
4
Select the device from the Device drop-down list.
5
Select Setup | Decryption | SSL Decryption.
6
Select Enable SSL Decryption on this Device to enable SSL decryption on the Sensor.
Current State indicates whether or not SSL decryption on the Sensor is currently enabled.
7
Optionally, select Yes for Include Decryption SSL Packets in the Packet Captures?
8
Enter the required value for SSL Flows value.
This value represents the number of SSL flows that can be processed at a given time by a Sensor.
The value range is Sensor specific: for I-4000, the range is 100-100,000. When you click on this
field, the maximum number of SSL flows supported for the Sensor model is displayed by default.
You can also refer to the Network Security Platform Best Practices Guide for the number of SSL
flows for various Sensor models.
The number of supported SSL flows on a Sensor directly impacts the number of TCP flows that can
be processed simultaneously. Note the Maximum Number of Concurrent Flows Supported on this Device for the
information about the number of concurrent TCP flows supported for the selected Sensor.
McAfee Network Security Platform 8.1
IPS Administration Guide
479
17
Inspection of SSL traffic
Steps involved in configuring SSL decryption
9
Enter the number of minutes for SSL Cache Timer.
This time relates to session resumption in SSL. The value represents the length in time a session is
kept alive after the last connection closes. This value should be equal to or slightly longer than the
session cache time on the corresponding server.
Because one Sensor could be processing traffic destined to many servers, the number of sessions
the Sensor can maintain may be considerably lower than the number the servers can maintain. If
the Sensor runs out of session state, which is indicated by an alert in the Threat Analyzer, some
flows will not be processed.
Figure 17-1 Enable area
10 Click Save.
11 Click Manage and select the domain to which the Sensor belongs. Then go to Troubleshooting | System
Faults and view the critical messages for the corresponding Sensor to see if a Sensor reboot is
required. If yes, then do a Hitless or Full reboot of the Sensor.
Management of the imported SSL keys of a device
In the Manager, you can import, re-import, and delete the private SSL certificates of the web servers
that you want a specific Sensor to protect. All these actions require a configuration update for the
changes to take effect. The Manager stores these keys in an encrypted format and sends them to the
corresponding Sensor when you do a configuration update. If a Sensor reboots, it automatically
requests the Manager for its SSL keys.
You need to manage the SSL keys on a per Sensor basis. For example, if there are two different data
paths to a server that are protected by two different Sensors, then you must import the SSL key of the
server separately for both the Sensors. In case of failover Sensors, the SSL keys on the primary is
automatically copied over to the secondary.
Import SSL keys to the Manager for a Sensor
You can download Secure Socket Layer (SSL) keys to Manager for a single Sensor. Once imported to
Manager, keys can be pushed to the Sensor via Update Configuration. Using provided SSL keys, a Sensor
can decrypt SSL traffic for IPS inspection. Manager provides a passthru interface for you to import a
set of public/private keys to the Sensor. 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,Manager uses the public key of the Sensor's public/private
key pair.
480
McAfee Network Security Platform 8.1
IPS Administration Guide
Inspection of SSL traffic
Steps involved in configuring SSL decryption
17
Network Security Platform maa supports PKCS12 keys with file suffixes ".pkcs12", ".p12", or ".pfx".
I-series Sensors (other than I-1200 and I-1400) can support up to 64 SSL certificates. M-series Sensors
(other than M-1250 and M-1450) can support up to 256 SSL certificates.
Task
1
Click
(Devices) and select the Domain.
2
Click
and select the Device.
3
Go to Setup | Decryption | Certificate Management | Import.
Figure 17-2 Key Import sub-tab
4
Type an Alias Name.
This name identifies the SSL key file in Manager.
5
Type the Passphrase.
This phrase was used for encrypting your PKCS12 file.
6
Locate the key PKCS12 File on your client system by clicking Browse.
7
Click Import.
A pop-up window opens detailing import status.
8
Download the SSL key(s) to a Sensor by updating configuration changes to the Sensor.
Re-import an SSL certificate file
You can re-import a previously imported SSL certificate file to the IPS Sensor as long as the escrow of
the previously imported certificate still resides on Manager.
Task
1
Click
(Devices) and select the Domain.
2
Click
and select the Device.
3
Go to Setup | Decryption | Certificate Management.
McAfee Network Security Platform 8.1
IPS Administration Guide
481
17
Inspection of SSL traffic
SSL best practices
4
Select Configuration Update for the certificate that you want to re-import.
5
Click Re-import.
6
Type the Passphrase related to the PKCS12 file.
7
Locate the key PKCS12 file on your client system by clicking Browse.
The name of the PKCS12 file can be different from before.
8
Click Apply.
A pop-up window details import status.
9
Do a configuration update to the Sensor.
Delete SSL certificates
Task
1
Click
(Devices) and select the Domain.
2
Click
and select the Device.
3
Go to Setup | Decryption | Certificate Management.
4
In the Certificate Management page, select the Configuration Update for the certificate you want to delete.
5
Click Delete and confirm the deletion.
6
Do a configuration update for the Sensor to delete the certificate from the Sensor.
SSL best practices
Note that there is a performance impact when using the SSL decryption feature. If there is a lot of
outbound SSL traffic from the client to the internet as well, it consumes SSL flows. Therefore, to
enable the Sensor to effectively utilize the SSL decryption feature, it is recommended to bypass these
outbound SSL traffic using ACL IGNORE rules.
Refer to the following sections for the SSL throughput measurements and test methodologies.
SSL only traffic — throughput: I-series Sensors
482
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 5K response each
•
128-bit ARC4
I-2700
I-3000
I-4000
I-4010
Max. SSL Connections / Sec.
325
600
800
1200
Throughput (Mbps) - 1024 bit key length
85 Mbps
155 Mbps
200 Mbps
310 Mbps
Throughput (Mbps) - 2048 bit key length
65 Mbps
115 Mbps
125 Mbps
250 Mbps
McAfee Network Security Platform 8.1
IPS Administration Guide
17
Inspection of SSL traffic
SSL best practices
SSL only traffic — throughput: I-series and M-series Sensors
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
•
128-bit ARC4
I-2700
I-3000
I-4000
I-4010
Max. SSL Connections / Sec.
300
400
800
800
Throughput (Mbps) - 1024 bit key length
150 Mbps
200 Mbps
400 Mbps
400 Mbps
M-2750
M-2850
M-2950
M-3050
M-4050
M-6050
M-8000
Max. SSL Connections / Sec. 550
750
1300
2700
4500
8500
Throughput (Mbps) - 1024
bit key length
250 Mbps
400 Mbps 600 Mbps 1200 Mbps 2 Gbps
Throughput (Mbps) - 2048
bit key length
200 Mbps
320 Mbps 320 Mbps 550 Mbps
3.8 Gbps
600 Mbps 1.2 Gbps
SSL traffic mixed with HTTP 1.1 traffic: I-series Sensors
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 5K response each
•
1024-bit RSA
•
128-bit ARC4
I-2700
Max. SSL Connections / Sec.
100
200
SSL Throughput
25 Mbps
50 Mbps
HTTP 1.1 Throughput
475 Mbps
350 Mbps
Total Throughput
500 Mbps
400 Mbps
Max. SSL Connections / Sec.
200
400
SSL Throughput
50 Mbps
105 Mbps
HTTP 1.1 Throughput
860 Mbps
475 Mbps
Total Throughput
910 Mbps
580 Mbps
I-3000
I-4000
Max. SSL Connections / Sec.
400
800
SSL Throughput
100 Mbps
200 Mbps
HTTP 1.1 Throughput
1550 Mbps
780 Mbps
Total Throughput
1650 Mbps
980 Mbps
I-4010
Max. SSL Connections / Sec.
400
800
SSL Throughput
100 Mbps
200 Mbps
McAfee Network Security Platform 8.1
IPS Administration Guide
483
17
Inspection of SSL traffic
SSL best practices
I-4010
HTTP 1.1 Throughput
1740 Mbps
860 Mbps
Total Throughput
1840 Mbps
1060 Mbps
SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 5K response each
•
128-bit ARC4
M-2750 / M-2850
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
110
110
SSL Throughput
50 Mbps
40Mbps
HTTP 1.1 Throughput
500 Mbps
500 Mbps
Total Throughput
550 Mbps
540 Mbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
180
180
SSL Throughput
80 Mbps
60 Mbps
HTTP 1.1 Throughput
900 Mbps
900 Mbps
Total Throughput
980 Mbps
960 Mbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
220
220
SSL Throughput
100 Mbps
90 Mbps
HTTP 1.1 Throughput
1.2 Gbps
1.2 Gbps
Total Throughput
1.3 Gbps
1.1 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
440
440
SSL Throughput
200 Mbps
150 Mbps
HTTP 1.1 Throughput
2.5 Gbps
2.5 Gbps
Total Throughput
2.7 Gbps
2.6 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
880
880
SSL Throughput
440 Mbps
400 Mbps
M-2950
M-3050
M-4050
M-6050
484
McAfee Network Security Platform 8.1
IPS Administration Guide
Inspection of SSL traffic
SSL best practices
1024 bit key length
2048 bit key length
HTTP 1.1 Throughput
4 Gbps
3.9 Gbps
Total Throughput
4.4 Gbps
4.3 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
1750
1750
SSL Throughput
800 Mbps
700 Mbps
HTTP 1.1 Throughput
8 Gbps
7.9 Gbps
Total Throughput
8.8 Gbps
8.6 Gbps
17
M-8000
SSL only traffic - throughput: NS-series Sensors
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
•
128-bit ARC4
NS 9100
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
17000
13600
SSL Throughput
8 Gbps
5.5 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
22000
15400
SSL Throughput
10 Gbps
6 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
44000
30800
SSL Throughput
20 Gbps
12 Gbps
NS 9200
NS 9300
SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors
•
Session resumption for 4 out of 5 TCP connections
•
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
•
128-bit ARC4
NS 9100
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
2300
2300
SSL Throughput
1 Gbps
1 Gbps
HTTP 1.1 Throughput
9 Gbps
9 Gbps
Total Throughput
10 Gbps
10 Gbps
McAfee Network Security Platform 8.1
IPS Administration Guide
485
17
Inspection of SSL traffic
SSL best practices
NS 9200
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
4600
4600
SSL Throughput
2 Gbps
2 Gbps
HTTP 1.1 Throughput
18 Gbps
18 Gbps
Total Throughput
20 Gbps
20 Gbps
1024 bit key length
2048 bit key length
Max. SSL Connections / Sec.
9200
9200
SSL Throughput
4 Gbps
4 Gbps
HTTP 1.1 Throughput
36 Gbps
36 Gbps
Total Throughput
40 Gbps
40 Gbps
NS 9300
486
McAfee Network Security Platform 8.1
IPS Administration Guide
18
How McAfee identifies applications?
M-series Sensors can identify the applications being used in your network and act on them. So, you
can allow or block specific applications on your network. For example, you can block just the
connections to Facebook from your network while allowing all other HTTP and HTTPS traffic. Using
advanced Quality of Service (QoS) policies, you can also control the bandwidth allocated for
applications on your network.
In addition to controlling the applications on your network, you can also view the Internet applications
that are accessed from your network. Related details such as the network bandwidth consumed by
specific applications is now available. You can also check if these applications generated any attacks.
Application identification is used in the following features: Firewall policies involving applications, QoS
policies involving applications, and Top Applications Summary monitor. So, to use these features
effectively, you need to understand how application identification works.
With respect to the application identification feature of Network Security Platform , the following are
referred to as applications:
•
Network connections over a specific protocol; for example, HTTP, DHCP, and FTP.
•
A specific computer application accessed over a network; for example, Facebook, Yahoo! Instant
Messenger, and GMail.
McAfee creates signatures for applications based on an ongoing research. This involves creating
signatures for applications for which there were no signatures earlier. This also involves removing
signatures for invalid and obsolete applications. These application signatures enable the Sensors to
accurately detect the applications on your network.
The application signatures are bundled as part of the regular signature set that the McAfee Update
Server downloads to the Manager. So, if the Manager is connected to the McAfee Update Server, the
application database of your Network Security Platform remains up-to-date.
Contents
Applications
Applications-related terminologies
How application identification works?
McAfee Network Security Platform 8.1
IPS Administration Guide
487
18
How McAfee identifies applications?
Applications
Applications
With respect to the application identification feature of Network Security Platform , the following are
referred to as applications:
•
Network connections over a specific protocol; for example, HTTP, DHCP, and FTP.
•
A specific computer application accessed over a network; for example, Facebook, Yahoo! Instant
Messenger, and GMail.
McAfee creates signatures for applications based on an ongoing research. This involves creating
signatures for applications for which there were no signatures earlier. This also involves removing
signatures for invalid and obsolete applications. These application signatures enable the Sensors to
accurately detect the applications on your network.
The application signatures are bundled as part of the regular signature set that the McAfee Update
Server downloads to the Manager. So, if the Manager is connected to the McAfee Update Server, the
application database of your Network Security Platform remains up-to-date.
Applications-related terminologies
Knowing the terminologies can enable you to understand how to use the application identification
feature better.
Application category
McAfee categorizes similar applications into categories. Based on its functions and features, an
application could belong to multiple categories. For example, Skype could belong to instant
messaging, file sharing, and voice over categories.
Typically, a category consists of applications that you would want to handle in a similar manner.
Therefore, categories can reduce the number of Firewall access rules that you would require. For
example, you can create a rule to block the webmail category instead of creating separate rules for
each webmail application.
Application capability
Using Network Security Platform, you cannot only control specific applications but also specific
features of applications. For example, you can block the file transfer feature of Yahoo! Messenger while
allowing its other features. Similarly, you can apply rate-limiting rules for specific application features.
To provide such granular control, McAfee creates signatures for some of the critical and common
features of applications. These features for which signatures exist are referred to as application
capabilities.
Functionally, Network Security Platform treats an application capability as an application itself. This is
because application capabilities also can belong to an application category. This category could be
different from the category to which the parent application belongs. However, a Firewall access rule for
an application may affect a rule written for a corresponding application capability. For example,
consider that you have a rule to allow Yahoo! Messenger followed by a rule blocking file transfer
through Yahoo! Messenger. Now, a user will be able to use Yahoo! Messenger's file transfer
functionality because this traffic matches the first rule that allows Yahoo! Messenger.
Application capabilities are listed along with the applications in the Rule Objects page.
488
McAfee Network Security Platform 8.1
IPS Administration Guide
How McAfee identifies applications?
How application identification works?
18
Risk
For you to understand the impact of applications and Application Capabilities on your network,
McAfee® Labs rates them as high, medium, or low risk. Risk is calculated based on the following
factors:
•
Vulnerability of an application or application capability to attacks.
•
The probability of an application or application capability to deliver malware.
How application identification works?
Similar to attack detection, application identification is a function of the Sensor. The Sensor can
identify applications in SPAN, tap, and inline modes. However, only inline mode is relevant for QoS. By
default the application identification feature is disabled. If you use any of the following features, then
application identification function is automatically turned on for that Sensor:
•
A Firewall access rule or any type of QoS rule based on an Application, Application on Custom Port,
or an Application Group.
•
Application identification enabled for the Top Applications Summary monitor.
Identifying applications is a resource-intensive process. If the Sensor performs application identification
on the entire traffic, the Sensor throughput could be reduced by about 10%. The amount of actual
throughput drop varies based on the type of traffic.
From a Firewall and QoS perspective, you need to understand how rules based on applications can
induce a dependency factor between the rules. The dependency factor with respect to Firewall is
explained here, but it has a similar effect on QoS policies as well.
There are four response actions that you can specify in case of Firewall:
•
Inspect — The Sensor permits the traffic that matches a Firewall access rule, but inspects it for
attacks. This applies to SPAN, tap, and inline modes.
•
Drop — The Sensor discards the traffic. This applies only to inline mode.
•
Deny — The Sensor drops the traffic and does a TCP reset. This applies only to inline mode.
•
Ignore — The Sensor permits the traffic with no further inspection. This applies to SPAN, tap, and
inline modes.
The dependency factor explained below, applies only for those rules for which you set inspect or
ignore as the Sensor's response action.
Dependency factor: If you create a rule to allow an application, all the dependent applications and
services are allowed by default. For example, if you allow Facebook then HTTP is allowed by default.
This also allows all unknown HTTP applications; that is HTTP applications for which there are no
signatures. For example, to allow Facebook but block all other HTTP traffic you need to create access
rules for the following conditions and in the same order:
•
Inspect Facebook
•
Deny HTTP
Consider that a user attempts to access Gmail, which is a known application. So, the Sensor identifies
the Gmail traffic and blocks it according to the second rule. Now, consider that a user attempts to
access an unknown HTTP application. The Sensor cannot identify this application beyond the HTTP
McAfee Network Security Platform 8.1
IPS Administration Guide
489
18
How McAfee identifies applications?
How application identification works?
level because there is no signature. Because the first rule implicitly allows HTTP, the Sensor allows this
traffic to pass through. In short, all unknown HTTP applications are allowed, and all known HTTP
applications except Facebook are blocked.
Suppose if you create Access Rules for the following conditions and in the same order then all HTTP
applications, including Facebook, are blocked:
•
Deny HTTP
•
Inspect Facebook
Similarly, rules involving application capabilities also can induce the dependency factor. That is,
allowing an application capability allows the application itself and other capabilities of the application
for which there are no signatures.
When you calculate the dependency factor between access rules, factor in all the components of the
rules such as source, destination, effective time, application categories, and so on. Consider the
sample set of rules below:
1
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Inspect (that is, permit with
IPS)
2
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
3
Source: a ¦ Destination: b ¦ Application: Twitter ¦ Response action: Drop
When the Sensor detects Twitter traffic from x to y, it allows this traffic with IPS, though it must drop
this traffic according to the second rule. This is because, TwileShare is dependent on Twitter. So, by
allowing TwileShare in the first rule from x to y, you are allowing Twitter from x to y as well. However,
if the Sensor detects Twitter traffic from a to b, it drops the traffic according to the third rule, because
the first rule that implicitly allows Twitter applies only from x to y and not from a to b.
Consider the rules below:
1
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
2
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Inspect (that is, permit with
IPS)
In this case, Twitter traffic from x to y is dropped according to rule 1; TwileShare traffic from x to y is
allowed with inspection according to rule 2.
490
McAfee Network Security Platform 8.1
IPS Administration Guide
19
Working with Reconnaissance policies
Reconnaissance policies enable you to prevent correlation-based attacks. These include host sweeps,
TCP or UDP port scans, email 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. The user
interfaces for Reconnaissance policies and the method of implementing them are to some extent
similar to that of IPS policies. Therefore, familiarize yourself with how to work with IPS policies before
you proceed to use Reconnaissance policies.
Reconnaissance policies management
Managing the Reconnaissance policies is similar to that of managing IPS policies. You can select the
reconnaissance attacks you want to protect against, the types of automatic responses you need to
block current or further impacts, and the methods of notification that will help your team respond to
malicious use of your network in the most expeditious time.
This section refers you to the Working with IPS policies section for information that is similar to IPS
policies. Note the following:
•
The Default Reconnaissance policy is the only pre-defined policy for reconnaissance. You cannot
delete this policy but clone or modify it to suit your needs.
•
The concept of rule sets does not apply to Reconnaissance policy. When you create a
Reconnaissance policies, all the attack definitions in the Signature Set are directly listed within the
policy.
•
The Default Reconnaissance policy is applied by default when you deploy a Sensor. You can
reassign a custom policy if required. The process of applying a Reconnaissance policy is similar to
that of IPS policies. However, you cannot assign Reconnaissance policies to interfaces or
subinterfaces; you can apply a Reconnaissance policy to the entire Sensor.
•
The following features are similar to that of IPS policies. So, refer to Working with IPS policies for
information:
•
Version control options for Reconnaissance policies
•
Adding annotations to an attack definition.
•
The Default IPS Attack Settings (formerly Global Attack Response Editor (GARE)) attack editor.
•
Attack Description
•
Export and import of Reconnaissance policies
•
Alert Suppression
•
Global Auto Acknowledgement for alerts
McAfee Network Security Platform 8.1
IPS Administration Guide
491
19
Working with Reconnaissance policies
Reconnaissance policies management
•
Scanning Exceptions
•
Exceptions (formerly Attack Filters)
The Reconnaissance Policy Editor provides the following actions:
•
Adding policies from the Reconnaissance Polices
•
Cloning a reconnaissance policy
•
Viewing/editing reconnaissance policies. To make modifications to a reconnaissance policy try the
following:
•
If you intend to try cloning a reconnaissance policy, make slight changes to a policy and save it
under a different name.
•
If you edit the Default Reconnaissance policy and later want to recreate that policy as it was
when provided by McAfee, simply revert to the earlier version of the policy. If you deleted the
earlier versions, add a policy. Remember to reassign the policies applied to your Sensors
accordingly so that they use your newly created policy.
•
If setting the same responses for several attacks serves your policy customization (for example,
enabling the Drop Packets response for all high severity attacks once you have enabled inline
mode), try the Bulk Edit option.
The Reconnaissance Policies page, the Last Modified column displays the time stamp of when a policy was
last modified. The Last Modified By column displays the logon name of the user who modified it. For
policies defined in the Central Manager, the Last Modified By column shows NSCM Defined Policy as the
value.
•
Modifying selected reconnaissance policies using Bulk Edit. Refer to Working with IPS policies since
the steps are similar to that of IPS policies.
•
Deleting a reconnaissance policy
Before you edit a Reconnaissance policy, make sure it is not in use in any of the child admin domains.
Before you delete a Reconnaissance policy, make sure it is not assigned to any Sensors.
You can enforce reconnaissance policy (scans, probes, and so forth) across all Sensor interfaces by
enabling/disabling one or more reconnaissance attacks. You can customize thresholds, responses, and
user notifications for each reconnaissance attack discovered by a Sensor's interfaces. Reconnaissance
attacks can cover a broad range of network segments and addresses, and therefore not visible a single
interface; thus, the entire Sensor is used to find these attacks. Thus, reconnaissance policy is enforced
at the Sensor level rather than VIPS (interface/subinterface) level due to the widespread nature of
reconnaissance attacks. Thus, the Sensor performs correlation for reconnaissance attacks to fully see
the extent of a single reconnaissance attack, and to throttle all instances of an attack from a single
source into one alert instance.
You can enable reconnaissance attack detection to be done on a VLAN basis. For more information,
see the McAfee Network Security Platform CLI Guide. The VLAN ID is included in reconnaissance alert
messages.
In case of a fail-over pair, the feature has to be enabled on both the Sensors.
Reconnaissance policies are applied to all interfaces on a Sensor; you cannot apply these policies to
individual interfaces. Use the link in the Assigned Resources column to assign the corresponding policy to
the required Sensor.
492
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with Reconnaissance policies
Reconnaissance policies management
19
Add a Reconnaissance policy
Task
1
In the Manager, click Policy and select the domain from the Domain drop-down list.
2
Select Intrusion Prevention | Reconnaissance Policies.
3
Click New.
The Add a Reconnaissance Policy dialog opens with the attribute values of the selected policy.
4
Type a name for your policy.
If you want this policy to be applicable in all created child admin domains, select the Visible to Child
Admin Domains checkbox.
5
Click Reconnaissance Attacks.
From 8.0, some of the scan and sweep Reconnaissance attacks are disabled by default for fresh
installation of Manager and will not have a checkmark in the Enabled column. But, when you upgrade
from a lower version to 8.0, these attacks are enabled by default.
Figure 19-1 Reconnaissance Attacks tab
McAfee Network Security Platform 8.1
IPS Administration Guide
493
19
Working with Reconnaissance policies
Reconnaissance policies management
6
Do one of the following:
•
Select a single attack row for customization and click View/Edit.
•
Select two or more attacks (CTRL+Left-Click or SHIFT+Left-Click) and click Bulk Edit to make
changes to more than one attack at a single time. Bulk editing is recommended for assigning
the same response to multiple attacks at the same time.
A pop-up details the attacks.
•
Click Cancel to end customization.
•
Check Customize to customize changes.
•
Click OK at any time to save your customizations and close the pop-up.
•
Click Clear Custom to reset the attack defaults.
Figure 19-2 Edit Reconnaissance Attack Details dialog
494
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with Reconnaissance policies
Reconnaissance policies management
7
19
View the name and severity of the attack. (Only the Customize Severity field displays when bulk
editing.) The fields are as follows:
•
Attack Name — Network Security Platform-designated name for attack.
•
Customize Severity — Impact potential of attack.
•
Attack Description — Click to view full description of attack. For more information, see Viewing
attack descriptions.
•
Annotate Description — Click to add your annotations for an attack in the attack encyclopedia.
•
Benign Trigger Probability — Probability the search for this attack will return a false positive.
(Optional) Change the Customize Severity drop-down list to change the severity.
8
The Threshold of the attack is determined by the botnet detection engine. So, a static threshold is
not required here.
Figure 19-3 Threshold settings
9
Select the Response section.
The Send Alert to the Manager checkbox is selected by default. If you deselect it, alerts for this attack
are not sent to the database and the attack is listed without a check in the Enabled field of the Add a
Reconnaissance Policy main dialog.
For some of the scan and sweep Reconnaissance attacks, the Send Alert to the Manager checkbox is
deselected by default.
Figure 19-4 Response settings
10 Select the Notifications section.
(Optional) Select a user notification. It is recommended you use these options for those attacks
within the highest severity range:
•
Email — sends an email to registered account users.
•
Pager — sends a page to registered account users.
•
Script — runs a script locally on a registered user account. The script must be previously
uploaded to the database.
•
SNMP — sends a message to SNMP server.
McAfee Network Security Platform 8.1
IPS Administration Guide
495
19
Working with Reconnaissance policies
Reconnaissance policies management
•
Syslog — sends a message to syslog server.
You do not have to set a notification for every attack; rather,McAfee recommends you only set
notifications for attacks that warrant your immediate attention. In the Severity Level, select By Attack
for the notification methods you employ.
•
Auto. Acknowledge — automatically marks the attack as acknowledged in the database. Thus, the
detection of the attack is not counted in the Unacknowledged Alert Summary (of the Manager Home
page), and can only be viewed in the Threat Analyzer during historical view queries.
Figure 19-5 Notifications settings
11 Click OK to accept the changes and enable the scan policy.
The pop-up closes. A check appears in the Customized column of the Add a Reconnaissance Policy window
for the attack you modified.
12 Click Save to save your changes, or click Ignore Changes to cancel your most recent changes.
13 Enter a Comment in the Enter Comment field. Then click Finish.
Figure 19-6 Enter comment window
14 Update the corresponding Sensors of the changes.
496
McAfee Network Security Platform 8.1
IPS Administration Guide
Working with Reconnaissance policies
Reconnaissance policies management
19
Assign reconnaissance policies to Sensors from the
Reconnaissance Policies page
Before you begin
Make sure the reconnaissance policies that you want to assign to the Sensors are available.
Although IPS policies are not customizable at the Sensor level, reconnaissance attack enforcement is.
Reconnaissance attacks, such as port scans and host sweeps, are customized at the Sensor level
because these types of attacks are often spread out across a network and are not easily detected in
the traffic monitored by a single interface. By enforcing the reconnaissance detection at this level, a
broader view of network activity can be achieved.
When you create an admin domain, you can select the default IPS and reconnaissance policies for that
admin domain. When you add a Sensor to that domain, these policies are applied to it by default. You
can assign a different reconnaissance policy to that Sensor from its Protection Profile page. An alternative
method is to assign the reconnaissance policy from the Reconnaissance Policies page itself. This is
especially useful when you want to define a reconnaissance policy and also quickly assign it to a
Sensor.
Task
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | Reconnaissance Policies.
4
Click the Assigned Resources value of the policy that you want to assign.
McAfee Network Security Platform 8.1
IPS Administration Guide
497
19
Working with Reconnaissance policies
Reconnaissance policies management
5
Assign the Reconnaissance policy to the required Sensors.
Figure 19-7 Assignments window
Table 19-1 Option definitions
Option
Definition
Search Resources
To filter the list of available resources, enter a string that is part of the Available
Resources.
Available Resources Lists the Sensors in the admin domain. The Sensors to which you have already
assigned this reconnaissance policy are displayed under Selected Resources.
Select a Sensor and click
Current Policy
to move it to Selected Resource.
The reconnaissance policy that is currently assigned to a Sensor. To replace that
policy with the policy that you are currently assigning, move the resource to
Selected Resource.
Selected Resources Lists the Sensors to which you have assigned the selected reconnaissance policy.
If you move a Sensor from Selected Resources to Available Resources for a
reconnaissance policy, then the corresponding admin domain's reconnaissance
policy is applied to that Sensor by default. That is, the Sensor's reconnaissance
falls back to the admin domain's reconnaissance policy.
6
498
Reset
Reverts to last saved configuration.
Save
Saves the changes to the Manager database.
Cancel
Closes the Assignments window without saving the changes.
Do a configuration update for the corresponding Sensors to enforce the policy.
McAfee Network Security Platform 8.1
IPS Administration Guide
20
Firewall policies
Firewall policies are ordered rules for permitting and denying traffic from reaching a Sensor's IPS/IDS
engine and continuing on through the network. Firewall policies can maximize a Sensor's detection
and prevention capabilities by preventing, that is dropping or rejecting, specified traffic without
requiring full inspection.
In Network Security Platform, a Firewall policy consists of an ordered set of rules that govern what
traffic is allowed to pass to a Sensor's inspection engine and beyond. These rules also govern which
traffic should be denied, that is either dropped from the network or rejected (TCP traffic only). Thus,
this feature enables the Sensor to preemptively drop any traffic by denying access to the inspection
engine and beyond.
You can enforce policies based on various parameters. You can base it on the application, Windows
Active Directory (AD) user names and user groups, the source or destination country of the traffic, the
source or destination network, the source or destination host, and so on.
You can control the traffic both at a broader as well as at a granular level. For example, you can deny
all TCP traffic that is using a specific port. You can also define a policy to prevent specific users from
accessing specific social-networking sites between 9 am and 5 pm on all week days. Thus, Firewall
policies provides you with very flexible options to control the traffic that is entering or leaving your
network.
The Firewall feature of Network Security Platform is independent of McAfee® Firewall Enterprise. This
section discusses only the Firewall feature of Network Security Platform.
Advantages of Firewall policies
Some of the advantages of using Firewall policies are as follows:
•
It can provide you visibility to a very granular level. For example, you can identify the users who
are trying to use a blocked application, such as Facebook.
•
You can enforce different policies based on time. For example, you can allow gaming applications
on weekends but block them during weekdays.
•
You can control traffic based on geographical locations.
•
You can control specific phases of an application. For example, you can allow chatting using Yahoo!
Messenger but deny file transfers.
•
You can enforce different policies for different sub-networks within your enterprise network. For
example, you can have very stringent policies for your finance network compared to your
engineering network.
•
You can choose to enforce IPS on the allowed traffic, thus fully securing your network. Conversely,
you can use the Firewall policies to exempt specific traffic from IPS inspection.
Contents
Types of Firewall policies
McAfee Network Security Platform 8.1
IPS Administration Guide
499
20
Firewall policies
Types of Firewall policies
Components of Firewall policies
High-level steps for configuring Firewall policies
Application identification
User-based access rules
Configure Firewall policies
Using stateless access rules to save Sensor resources
How to view the details of matched traffic
Firewall-related capacity values
Types of Firewall policies
You can use two types of Firewall policies in Network Security Platform — advanced and classic.
Functionally, these two types are similar. However, as the names might suggest, advanced Firewall
policies provide you more options to filter traffic when compared to classic.
Notes:
•
Classic Firewall policy is the equivalent of the Access Control Lists (ACL) feature in Network
Security Platform releases prior to 7.0. If you had upgraded from a release prior to 7.0, where you
had configured ACLs, then these will appear as classic Firewall policies post-upgrade. Refer to
McAfee Network Security Platform 7.0 Upgrade Guide for details.
•
All Sensor models support classic Firewall policies.
•
Only Virtual IPS Sensors and M-series Sensors running on software version 7.0 and above support
advanced Firewall policies.
Table 20-1 Differences between advanced and classic Firewall policies
Advanced
Classic
Supporting device
M-series Sensors running on software version 7.0
or above.
All Sensor models.
Options on source or
destination of the traffic
Source or destination are based on:
Source or destination
are based on:
• Country
• A host's DNS name
• A host's IPV4
address
• A host's IPv4 or IPv6 address
• IPv4 Network
• An IPv4 or IPv6 address range to which a host
belongs.
• IPv4 or IPv6 networks or a group of IPv4 or IPv6
networks.
• Windows Active Directory user names and user
groups
Options on the traffic
Traffic is based on:
• A specific or a group of Layer 7 applications. For
example, you can filter out Yahoo! Games while
allowing Yahoo! Mail. These applications can be
on the standard or custom communication ports.
Traffic is only based
on the IP protocol or
the TCP/UDP port
numbers.
• IP protocol or the TCP/UDP port numbers.
500
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Components of Firewall policies
20
Table 20-1 Differences between advanced and classic Firewall policies (continued)
Advanced
Classic
Option to enforce the
Firewall policy based on
time.
Yes. For example, the Sensor can enforce a policy
on all weekends only.
No.
Option to define a rule
that mandates AD
authentication
Yes.
No.
Components of Firewall policies
To effectively use Firewall policies, familiarize yourself with the components of Firewall policies.
•
Firewall policies — These are your network security policies based on which the Sensor allows or
blocks traffic in and out of your network. There are two types of Firewall policies — advanced and
classic.
•
Access rules —Access rules are the building blocks of a Firewall policy. Access rules are Access
Control Lists (ACLs) – an ordered set of rules, which define the traffic to be allowed and the traffic
to be blocked.
•
Rule objects — You use rule objects to define access rules. Rule objects are mappings to one or
more components related to your network traffic. Examples of rule objects are the applications,
source and destination hosts, source and destination networks. So, for example, you can group a
set of IPv4 addresses to create a rule object. Then you can create an access rule in which you
specify this rule object as the source or destination of traffic. Every time you want to refer to this
set of IP addresses in your access rules, you can just use this rule object.
For advanced and classic Firewall policies, you can specify multiple rule objects per component of an
access rule. For example, you can specify multiple rule objects as the source of the traffic.
The following are the rule object types that are currently available:
•
User — These are the Windows AD users currently logged on to your network. The Manager
gathers this list from McAfee Logon Collector and provides it to the Sensor.
•
User Group — These are the user groups of the currently logged on users. The Manager
gathers this information from McAfee Logon Collector and provides it to the Sensor.
You cannot create, modify, or delete Users or User Groups in the Manager. You can view these
rule objects only in the Access Rules tab of the Firewall policies page. Regarding Users, you cannot
view the entire list even in the Firewall policies page; you can query for the required users when
defining the access rules. You cannot view the User or User Group rule objects in the Rule Objects
page.
•
Application — These are the various software programs that the Sensor can detect. The
Manager derives the list of applications from the signature set. You cannot modify the list of
available applications. Applications are relevant only to advanced Firewall policies.
If McAfee Labs deprecates an application that you have used in a Firewall policy, then a fault
message of severity warning is raised. You will then have to delete those rules from the policies
or modify them; if not you will not be able to push a signature set to Sensors.
•
Application on Custom Port — You can use this rule object to detect applications when they
are communicated over non-standard ports. For example, you might want the Sensor to detect
FTP, when it is over port 2021. Application on Custom Port is relevant only to advanced Firewall
policies.
McAfee Network Security Platform 8.1
IPS Administration Guide
501
20
Firewall policies
Components of Firewall policies
•
Application Group — If the pre-defined Application Groups do not meet your requirements,
you can create one. You create an Application Group to combine more than one Application and
Application on Custom Port rule objects. Typically, you create an Application Group for those
applications that you want the Sensor to handle in a similar way. For example, you can combine
all applications related to Internet games to form one Application Group. You can group up to 10
items in an Application Group. Application Group is relevant only for advanced Firewall policies.
You can combine Application and Application on Custom Port rule objects to form an Application
Group. You cannot include Application Group within another Application Group.
•
Country — The Country rule object enables you to allow or block traffic based on the source or
destination country. The Sensor identifies the traffic originating or destined to these countries
based on the CIDRs mapped to the countries. Country is relevant only for advanced Firewall
policies.
The country-to-CIDRs mapping information is sourced from the geolocation database of
MaxMind. You cannot modify or update this list of countries manually. McAfee updates this list of
country-to-CIDRs mapping through signature sets. Use the Status command in a Sensor's CLI
to check if the geolocation database is present in the Sensor.
•
IPv4 Endpoint — You can create a list of source and destination IPv4 addresses that you want
to use in a Firewall rule. You can specify up to 10 IPv4 addresses in a rule object. If you have
enabled XFF header parsing in your Sensor, you will be able to use the original source IP
address of the for HTTP traffic.
•
IPv6 Endpoint — This is similar to the IPv4 Endpoint rule object but applies only to advanced
policies.
•
Host DNS Name — You can create the list of source and destination host names that you want
to use in a Firewall rule. The Sensor contacts the DNS servers that you configure to resolve
these names to IP addresses. For example, you can create a Host DNS Name rule object for
facebook.com, faceparty.co.uk, ibibo.com. You can add 10 Host DNS Names in a rule object.
Host DNS Name applies only to advanced Firewall policies.
The sensor uses only UDP and never falls back to TCP for DNS queries even if the DNS server
forces for TCP.
502
•
IPv4 address range — You can create the list of IPv4 addresses to use in a Firewall rule. In
the rule, you can specify an IPv4 address range as the source or destination of traffic. For
example, you may want to apply a rule to traffic from IPs ranging from 10.1.1.1 to 10.1.1.25.
This rule object applies only to advanced Firewall policies. You can specify up to 10 ranges in a
rule object. If you have enabled XFF header parsing in your Sensor, you will be able to use
original source IP addresses for HTTP traffic.
•
IPv6 address range — This is similar to the IPv4 address range.
•
IPv4 Network — You can create a list of IPv4 CIDRs to use in a Firewall rule. In the rule, you
can specify a CIDR as the source or destination of traffic. For example, you might want to apply
a rule on the traffic targeted for 172.16.225.0/24 network. The three reserved IPv4 ranges
according to RFC 1918 are provided as default networks. You can specify up to 10 CIDRs in one
rule object.
•
IPv6 Network — Similar to IPv4 Network but applies only to advanced Firewall policies. Also,
there are no predefined IPv6 Network rule objects in the Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Components of Firewall policies
•
20
Network Group — You can combine one or more Country, Host IP, Host Name, IP range, or
Network to form a Network Group. For example, you can combine all the North American countries
and multiple IP ranges to form a Network Group rule object. This rule object applies only to
advanced Firewall policies. You can specify up to 10 items in one Network Group rule object.
you cannot combine IPv4 and IPv6 based rule objects in the same Network Group rule object.
Note that Country and Host DNS are IPv4-based.
•
Finite Time Period — You can configure the Sensor to enforce an access rule continuously just
for a specific time period. For example, you might want to enforce a rule from 9 am on June 10
of this year to 10 am on June 11 of this year. For this, you need to create a Finite Time Period rule
object specifying the start time and date along with the end time and date. The start and end
time are both inclusive. Finite Time Period applies only to advanced Firewall policies. You can
specify only one Finite Time Period rule object in a Firewall access rule.
When you use a time-based rule object, make sure you have configured the corresponding Time
Zone. The Sensor automatically factors in the daylight savings time, if applicable. GMT is the
default Time Zone in the Manager.
•
Recurring Time Period — You can repeatedly enforce a Firewall rule at certain frequencies of
time. For example, you can enforce a rule from 9 am to 5 pm on all weekdays. Use this rule
object to repeatedly enforce a rule. To enforce a rule just once, use the Finite Time Period rule
object.
When you use a time-based rule object, make sure you have configured the corresponding Time
Zone. Note that the Sensor automatically factors in the daylight savings time, where applicable.
Recurring Time Period applies only to advanced Firewall policies.
•
Recurring Time Period Group — You can group up to 10 Recurring Time Periods to form a
Recurring Time Period Group rule object. Recurring Time Period Group applies only to advanced
Firewall policies.
You can use the Finite Time Period rule object along with Recurring Time Period and Recurring
Time Period Group rule objects. In such a case, the Finite Time Period takes precedence. Also,
for the Sensor to check for that access rule, the Finite Time Period and at least one Recurring
Time Period must be active.
•
Service — To restrict traffic based on the IP protocol, ICMP codes, or the TCP/UDP port
numbers, use the Service rule object. You can create Service rule objects or use the default
ones. The well-known services on standard TCP and UDP ports, as well as ICMP codes are
pre-defined. For example, telnet is predefined as TCP on port 23. Similarly, ICMP codes such as
ICMP echo reply and ICMP request are pre-defined. When you create a Service rule object, the
options are to specify the protocol number, TCP port, or UDP port. For custom ICMP codes, you
need to specify the IP protocol number and the ICMP code in the port field. You can define only
one IP protocol specification per rule object.
For access rules that use Service rule objects, the Sensor factors in any non-standard ports that
you have configured for IPS. For example, if you have specified port 2023 as the non-standard
port for FTP, and if you have used the FTP Service rule object in a rule, then the Sensor
considers FTP on both ports 21 and 2023.
For certain protocols, you can use more than a type of rule object. For example, for FTP and
HTTP, you can use the Application rule object or the Service rule object. If you use the
Application rule object, the Sensor does not consider the port number when detecting the
traffic, and relies only on the application signatures. This means that the Sensor can a detect a
protocol regardless of the port used in case of Application rule objects. If you use the Service
rule object, the port number matters when detecting a protocol. The Sensor considers all the
standard ports as well as non-standard port numbers that you have defined in the
Non-Standard Ports page.
McAfee Network Security Platform 8.1
IPS Administration Guide
503
20
Firewall policies
High-level steps for configuring Firewall policies
In case of Service rule object, the Sensor drops even the SYN packet. In case of Application rule
object, the Sensor drops the traffic only after the three-way handshake; only after the
handshake, the Sensor identifies the application.
A Sensor processes the access rules of a policy in a top-down fashion. So, if you want to drop
traffic based on Services, then define those access rules high up in the policy.
Note the following if you use classic Firewall policies:
•
•
It is not advisable to set permit rules for protocols such as FTP, TFTP, and RPC services that
negotiate ports dynamically. 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.
•
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 access rules to
deny these dynamic protocol instances by denying the fixed control port.
•
An option for denying protocols that use dynamic negotiation is to configure policies to drop
the attacks that are detected in such transmissions. Network Security Platform detects the
use of, and attacks in such programs as Yahoo Messenger, KaZaA, and IRC.
Service Group — You can group the services that you want to be handled in a similar manner.
This enables you to easily manage your Firewall policies. Service Group is relevant only for
advanced Firewall policies. You can group up to 10 services in one Service Group rule object.
Service Range is applicable only to QoS policies.
High-level steps for configuring Firewall policies
You create Firewall policies at the admin-domain level. Then, you assign these policies to the required
Sensor resources.
You can enforce Firewall policies with the monitoring ports in SPAN, tap, or inline mode. However,
factor in the mode when you specify the response action. For example, dropping the traffic is not a
relevant response in SPAN or tap mode.
You can enforce policies based on the application, Windows Active Directory (AD) user names and user
groups, the source or destination country of the traffic, the source or destination network, the source or
destination host, and so on. This section discusses how Firewall policies work in general. There are
some additional information that you must know if you plan to use access rules based on applications,
user names, or user groups. Also, there are additional configurations required for these features. The
concepts and requirements for application-based and user-based access rules are discussed in separate
sections that follow.
The following are the high-level steps involved in implementing Firewall policies:
504
1
Make sure you have deployed Network Security Platform as required.
2
Make sure you have connected the monitoring ports to the networks that you want to monitor.
3
In addition to Firewall, if you want the Sensor to inspect the traffic for attacks, make sure you have
configured the IPS or the IDS feature, and that the Sensor is detecting and reporting attacks.
4
Create the rule objects that you plan to use in your access rules. For example, identify the IPv4
Endpoint addresses and the IPv4 Address Range and create the corresponding rule objects.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
High-level steps for configuring Firewall policies
5
20
If you use the Host DNS Name rule object, make sure you configure the DNS server details in the
Manager. Also, make sure these servers are accessible to the Sensor's management port. If the
DNS servers are not accessible, a fault message is raised.
The DNS server details apply to Firewall policies, QoS policies, integration with GTI for File
Reputation, and NTBA.
6
If you are using any time-based rule objects, make sure you have configured the Time Zone in the
Manager. The preconfigured Time Zone is GMT.
7
Create the required Firewall policies at the corresponding admin domain. When you create the
Firewall policies, you will be defining the access rules. So, a policy contains an ordered set of
access rules that the Sensor processes in a top-down fashion.
8
After you create a Firewall policy, you need to assign it to a Sensor resource. The following are
referred to as Sensor Resources
•
Pre-device — This resource is the Sensor itself, and the Firewall policy assigned to this
resource is applied to all the traffic reaching the Sensor. This policy is referred to as the
pre-device policy. A pre-device Firewall policy has the highest priority. That is, the Sensor
matches the traffic against the access rules of this policy first. Typically, you will assign policies
that will block specific traffic across your network. For example, you might want to block p2p
traffic perpetually on your network.
•
Interface or subinterface — These resources are Monitoring ports of type VLAN or CIDR. You
can assign Firewall policies to interfaces or subinterfaces based on how you have configured the
Monitoring ports.
The Sensor considers the policy at the interface or subinterface after the policy assigned at the
pre-device level. The Sensor enforces this policy only on the traffic seen at the corresponding
interface or subinterface. So, typically you will assign policies that are very granular in nature in
terms of source and destination. For example, these could be policies targeted at specific hosts
or networks.
McAfee Network Security Platform 8.1
IPS Administration Guide
505
20
Firewall policies
High-level steps for configuring Firewall policies
•
Physical port level: Assign those policies that you want to enforce at a port level. Typically,
these policies will be less granular when compared to the policies assigned at the interface or
subinterface level. The Sensor considers the policy at this level after the policy at the interface
or subinterface.
•
Post-device — This resource is also the Sensor itself, similar to pre-device. However, the
post-device policy is applied only after all the policies assigned to the other Sensor resources.
You can have a unique Firewall policy to each Sensor resource, but only one Firewall policy per
resource. It is not mandatory to assign Firewall policies to Sensor Resources in any specific
order. For example, you can assign a policy only at the pre-device level or only at the
subinterface level.
Policies assigned at the Sensor level (pre and post-device) as well as the port/port pair are
inherited by the corresponding interface and, if applicable, subinterfaces. In the case of Firewall
policies, an interface is a subset of the corresponding port or port pair. That is, the policy
assigned for a port/port pair at the Sensor level is inherited by the corresponding interface as
well as any subinterfaces. However, a policy assigned at the interface level is not inherited by
the corresponding subinterfaces due to the rule of separating interface traffic flows from
subinterface traffic flows based on the following policy application rule: if you apply a policy to a
subinterface that is different than the inherited policy, the policy enforced at the interface level
protects all traffic not specific to the subinterface. Thus, for Firewall policies, the rule of
inheritance requires you to create global policies at the Sensor (pre and post-device) or physical
port/port pair level: interface policies only apply to interfaces, and subinterface rules only apply
to subinterfaces.
After you assign the Firewall policies, the Manager creates a collective list of all the access rules
in those policies. This is the list of Effective Firewall Rules that the Sensor processes in a top-down
fashion. That is, the rule at the top of the list is checked first, followed by subsequent rules
down to the bottommost rule. Network Security Platform employs a first-match process; the
first rule matched in sequence is enforced and the remaining rules are not processed.
The order of the rules in an Effective Firewall Rules list is based on the hierarchy of Sensor
resources. That is, the rules of the pre-device Firewall policy are listed on top followed by the
rules of the interface or subinterface policy, then followed by the port-level policy, and finally the
post-device level policy.
The Manager computes the Effective Firewall Rules separately for inbound and outbound.
You can view the Effective Firewall Rules in the Protection Profile page at the interface and sub-interface
levels.
9
After you complete assigning the Firewall policies to the required Sensor Resources, do a
configuration update.
10 You can configure the Sensor to send the details of the matched traffic to a syslog server for
analysis.
506
a
Configure a syslog server.
b
Enable syslog notification in the IPS Interfaces tab.
c
Also enable Firewall logging.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Application identification
20
Application identification
M-series Sensors can identify the applications being used in your network and act on them. So, you
can allow or block specific applications on your network. For example, you can block just the
connections to Facebook from your network while allowing all other HTTP and HTTPS traffic. Using
advanced Quality of Service (QoS) policies, you can also control the bandwidth allocated for
applications on your network.
In addition to controlling the applications on your network, you can also view the Internet applications
that are accessed from your network. Related details such as the network bandwidth consumed by
specific applications is now available. You can also check if these applications generated any attacks.
Application identification is used in the following features: Firewall policies involving applications, QoS
policies involving applications, and Top Applications Summary monitor. So, to use these features
effectively, you need to understand how application identification works.
With respect to the application identification feature of Network Security Platform , the following are
referred to as applications:
•
Network connections over a specific protocol; for example, HTTP, DHCP, and FTP.
•
A specific computer application accessed over a network; for example, Facebook, Yahoo! Instant
Messenger, and GMail.
McAfee creates signatures for applications based on an ongoing research. This involves creating
signatures for applications for which there were no signatures earlier. This also involves removing
signatures for invalid and obsolete applications. These application signatures enable the Sensors to
accurately detect the applications on your network.
The application signatures are bundled as part of the regular signature set that the McAfee Update
Server downloads to the Manager. So, if the Manager is connected to the McAfee Update Server, the
application database of your Network Security Platform remains up-to-date.
Applications-related terminologies
Knowing the terminologies can enable you to understand how to use the application identification
feature better.
Application category
McAfee categorizes similar applications into categories. Based on its functions and features, an
application could belong to multiple categories. For example, Skype could belong to instant
messaging, file sharing, and voice over categories.
Typically, a category consists of applications that you would want to handle in a similar manner.
Therefore, categories can reduce the number of Firewall access rules that you would require. For
example, you can create a rule to block the webmail category instead of creating separate rules for
each webmail application.
Application capability
Using Network Security Platform, you cannot only control specific applications but also specific
features of applications. For example, you can block the file transfer feature of Yahoo! Messenger while
allowing its other features. Similarly, you can apply rate-limiting rules for specific application features.
To provide such granular control, McAfee creates signatures for some of the critical and common
features of applications. These features for which signatures exist are referred to as application
capabilities.
McAfee Network Security Platform 8.1
IPS Administration Guide
507
20
Firewall policies
Application identification
Functionally, Network Security Platform treats an application capability as an application itself. This is
because application capabilities also can belong to an application category. This category could be
different from the category to which the parent application belongs. However, a Firewall access rule for
an application may affect a rule written for a corresponding application capability. For example,
consider that you have a rule to allow Yahoo! Messenger followed by a rule blocking file transfer
through Yahoo! Messenger. Now, a user will be able to use Yahoo! Messenger's file transfer
functionality because this traffic matches the first rule that allows Yahoo! Messenger.
Application capabilities are listed along with the applications in the Rule Objects page.
Risk
For you to understand the impact of applications and Application Capabilities on your network,
McAfee® Labs rates them as high, medium, or low risk. Risk is calculated based on the following
factors:
•
Vulnerability of an application or application capability to attacks.
•
The probability of an application or application capability to deliver malware.
View application categories
You can view the list of categories in the Rule Objects page.
Task
1
Click the Policy tab.
2
Select the domain from the Domain drop-down list.
3
Select Intrusion Prevention | Objects | Rule Objects.
4
From the Show drop-down, select Application Group.
The default Application Groups are the application categories.
Figure 20-1
List of application categories
To view the applications that belong to a category (a default Application Group), double-click a
default Application Group. In the Object Details window, select from the Available drop-down list and
click
icon.
The list of default Application Groups and the constituent Applications may change between versions
of the signature set.
508
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Application identification
20
How application identification works?
Similar to attack detection, application identification is a function of the Sensor. The Sensor can
identify applications in SPAN, tap, and inline modes. However, only inline mode is relevant for QoS. By
default the application identification feature is disabled. If you use any of the following features, then
application identification function is automatically turned on for that Sensor:
•
A Firewall access rule or any type of QoS rule based on an Application, Application on Custom Port,
or an Application Group.
•
Application identification enabled for the Top Applications Summary monitor.
Identifying applications is a resource-intensive process. If the Sensor performs application identification
on the entire traffic, the Sensor throughput could be reduced by about 10%. The amount of actual
throughput drop varies based on the type of traffic.
From a Firewall and QoS perspective, you need to understand how rules based on applications can
induce a dependency factor between the rules. The dependency factor with respect to Firewall is
explained here, but it has a similar effect on QoS policies as well.
There are four response actions that you can specify in case of Firewall:
•
Inspect — The Sensor permits the traffic that matches a Firewall access rule, but inspects it for
attacks. This applies to SPAN, tap, and inline modes.
•
Drop — The Sensor discards the traffic. This applies only to inline mode.
•
Deny — The Sensor drops the traffic and does a TCP reset. This applies only to inline mode.
•
Ignore — The Sensor permits the traffic with no further inspection. This applies to SPAN, tap, and
inline modes.
The dependency factor explained below, applies only for those rules for which you set inspect or
ignore as the Sensor's response action.
Dependency factor: If you create a rule to allow an application, all the dependent applications and
services are allowed by default. For example, if you allow Facebook then HTTP is allowed by default.
This also allows all unknown HTTP applications; that is HTTP applications for which there are no
signatures. For example, to allow Facebook but block all other HTTP traffic you need to create access
rules for the following conditions and in the same order:
•
Inspect Facebook
•
Deny HTTP
Consider that a user attempts to access Gmail, which is a known application. So, the Sensor identifies
the Gmail traffic and blocks it according to the second rule. Now, consider that a user attempts to
access an unknown HTTP application. The Sensor cannot identify this application beyond the HTTP
level because there is no signature. Because the first rule implicitly allows HTTP, the Sensor allows this
traffic to pass through. In short, all unknown HTTP applications are allowed, and all known HTTP
applications except Facebook are blocked.
Suppose if you create Access Rules for the following conditions and in the same order then all HTTP
applications, including Facebook, are blocked:
•
Deny HTTP
•
Inspect Facebook
Similarly, rules involving application capabilities also can induce the dependency factor. That is,
allowing an application capability allows the application itself and other capabilities of the application
for which there are no signatures.
McAfee Network Security Platform 8.1
IPS Administration Guide
509
20
Firewall policies
User-based access rules
When you calculate the dependency factor between access rules, factor in all the components of the
rules such as source, destination, effective time, application categories, and so on. Consider the
sample set of rules below:
1
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Inspect (that is, permit with
IPS)
2
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
3
Source: a ¦ Destination: b ¦ Application: Twitter ¦ Response action: Drop
When the Sensor detects Twitter traffic from x to y, it allows this traffic with IPS, though it must drop
this traffic according to the second rule. This is because, TwileShare is dependent on Twitter. So, by
allowing TwileShare in the first rule from x to y, you are allowing Twitter from x to y as well. However,
if the Sensor detects Twitter traffic from a to b, it drops the traffic according to the third rule, because
the first rule that implicitly allows Twitter applies only from x to y and not from a to b.
Consider the rules below:
1
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
2
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Inspect (that is, permit with
IPS)
In this case, Twitter traffic from x to y is dropped according to rule 1; TwileShare traffic from x to y is
allowed with inspection according to rule 2.
User-based access rules
Similar to application identification, the information in this section applies to advanced Firewall policies
and advanced QoS policies.
510
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
User-based access rules
20
For example, you can create access rules to allow a specific AD group of users to access
social-networking applications while blocking the same for some other group during business hours.
Such access rules where user data is also a criteria are referred to as user-based access rules.
Creating rules that are based on users and user groups is a better option than IP address based rules,
especially when the IP address are likely to change dynamically.
You cannot specify country and user name or user group in the same rule.
Figure 20-2 A deployment scenario for user-based access rules
To use user-based rules in your Firewall or QoS policies, you must install McAfee® Logon Collector 2.0
on your network and integrate it with the Manager. McAfee Logon Collector (Logon Collector) gathers
the details of the currently logged on users from the domain controllers. It then regularly updates
these details to the Manager. The Manager processes these details and passes them to the relevant
Sensors, which use them to evaluate the traffic and take the configured response action.
You can configure user-based access rules only in advanced Firewall and QoS policies.
You can create an advanced Firewall access rule with the Response set as Require Authentication. This option
indicates that you want the Sensor to ensure AD authentication of users if the traffic is HTTP. If the
Sensor does not have the AD details for a user, it mandates the user to provide the AD logon
credentials. The Manager then verifies these credentials with the AD server. So, the Sensor is aware
that the user has valid AD credentials and also has the AD user name to apply the correct rule.
McAfee Network Security Platform 8.1
IPS Administration Guide
511
20
Firewall policies
User-based access rules
Advantages
•
User-based rules enable you to effectively identify and regulate traffic originating in your network.
So, you can now control what your users can or cannot access regardless of the other criteria. In
case of QoS, you can apply traffic management techniques based on user groups.
•
Consider organizations where users work in shifts or where users log on from any available host;
that is, a host is not dedicated to any particular user. For such cases, user-based access rules can
provide the required control.
•
Bring Your Own Device (BYOD) environment is another scenario where user-based access rules can
be very useful. Using the Require Authentication option, you enforce your users to make their host to be
part of your corporate domain.
High-level steps for implementing user-based Firewall and QoS
rules
The following are the requirements for implementing user-based rules for Firewall and QoS:
•
Manager 7.5.3.x or above
•
M-series Sensors of software version 7.5.3.x or above
•
McAfee Logon Collector 2.0
•
Your AD server is configured correctly and that your users are able to logon to the domain.
•
You have deployed the required Sensor monitoring ports in SPAN, tap, or inline mode (for QoS,
only inline mode applies). Your Network Security Platform deployment is functioning as expected.
For example, in the segment where you have deployed the monitoring ports, legitimate traffic is
able to reach the destined hosts.
•
Optionally, you can log the results of each rule that the Sensor applied. For this you need a syslog
server.
To be able to configure and use Firewall policies, you must have administrator permissions for the IPS
environment of the Manager. If you are not sure, contact the administrator of the Manager server.
512
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
User-based access rules
20
The following are the high-level steps involved in implementing user-based access rules:
1
Install or upgrade McAfee Logon Collector to 2.0. You can install McAfee Logon Collector on your AD
server or on a different one. If you are installing it on a different server, make sure the McAfee
Logon Collector and the AD server are reachable to each other over the network. Refer to McAfee
Logon Collector Administration Guide for information on installation and upgrade.
2
Add the relevant domains in McAfee Logon Collector. After you have added the domains, the Status
in McAfee Logon Collector must be in green. If not, refer to McAfee Logon Collector documentation
to troubleshoot and fix the problems.
Figure 20-3 The status in McAfee Logon Collector
3
Make sure the IP, users, and computer details displayed in the Logon Report of theMcAfee Logon
Collector are accurate.
4
Integrate McAfee Logon Collector with the Manager. You can integrate only one McAfee Logon
Collector with the Manager. See Network Security Platform 7.1 Integration Guide for information.
If you implement Manager Disaster Recovery (MDR), then you must manually integrate the
secondary Manager with McAfee Logon Collector.
5
Optionally, configure the syslog details in the Manager to log the details related to Firewall access
rules.
6
As explained in the subsequent sections, the Manager receives the user details from McAfee Logon
Collector. Additionally, the Sensor also uses the Kerberos traffic to detect user details. For this
method to work, you must configure the details of the AD and Trusted Domain Controllers in the
Manager.
McAfee Network Security Platform 8.1
IPS Administration Guide
513
20
Firewall policies
User-based access rules
7
8
Configure user-based access rules in the Manager and apply it to the required Sensor resources. In
an access rule, you can specify the following as the criteria:
•
Up to 10 AD user names
•
Up to 10 AD user groups
•
A combination of AD user names and user groups not exceeding 10 in total.
View the access-rule related details in the Manager configuration report and in the syslog server.
How user-based access rules work
The way user-based access rules work can be explained in three parts:
1
How the Manager receives user details.
2
How the Sensor receives user details.
3
How the Sensor evaluates user-based access rules.
How the Manager receives user details
1
When you add the domains in McAfee Logon Collector, it contacts the AD server and collects the
details such as the IP address, user name, host name, and so on of the currently logged on users.
2
When you integrate McAfee Logon Collector and the Manager, McAfee Logon Collector sends all the
user details that it currently has, to the Manager. The information sent includes the following:
•
IP to user mapping
•
List of users and the user groups to which they belong
•
List of user groups
Communication between the Manager and McAfee Logon Collector is over SSL.
3
McAfee Logon Collector updates the Manager continuously. So, at any point in time, the current
user-related data with McAfee Logon Collector is there with the Manager as well.
Consider situations such as the following:
•
A user logs off from a host and a user logs on from that host again
•
You add a user to more user groups
•
You delete a user group in the AD
For all such cases, as soon as McAfee Logon Collector has the updated information, it is reflected in
the Manager as well.
When you add new users in the AD, modify user groups, or delete user groups you must run the
MLC Refresh Users server task manually in McAfee Logon Collector. Then the current data from the
AD is available in the Manager.
4
514
If you have configured MDR, then the process explained above happens independently for both the
Managers. The Managers themselves do not exchange any user details.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
User-based access rules
20
For the following cases, the information might not immediately reflect in the Manager:
1
If a user logs off from a host and no user is currently logged on
2
You remove a user from a user group
3
You delete a user group. In this case, the user attributes are updated but the deleted user group is
visible in the Manager
How the Sensor receives user details
1
2
The Manager sends user-data updates to Sensors when both of these conditions are met:
•
M-series Sensors running on 7.5.3.x or above.
•
At least one of the Sensor's resources has been assigned a user-based Firewall access rule or
QoS rule.
The updates to the Sensors includes the following information:
•
IP to user mapping
•
User to user group mapping
•
List of user groups
3
Manager sends the updates using TFTP (standard ports). It sends the updates to both the member
Sensors in case of failover.
4
The Manager updates the Sensor in two ways:
•
Full update - that is the Manager sends the entire set of user-data that it currently has to the
relevant Sensors. This update entirely refreshes the user-data on a Sensor.
•
Incremental update every one minute - the Manager sends just the changes since the last
update.
5
If you have an MDR, only the active Manager sends the updates to the Sensors. If you have a
failover pair of Sensors, then the active Manager sends the updates to both the Sensors. Whenever,
the active Manager goes down, the standby Manager sends a full update to the Sensors as soon as
it becomes the active Manager.
6
The Manager sends the full update under the following conditions:
•
Sensor reboot
•
If the communication channel between the Manager and Sensor that is used for the updates
comes up again
•
Manager restarts
•
By default, at 1200 hours everyday; this is not user-configurable
•
When a standby Manager in an MDR pair becomes the active Manager
•
When connection between the Manager and McAfee Logon Collector is re-established
The Manager re-sends an update until it succeeds.
Deriving user details using Kerberos traffic: If the Manager-McAfee Logon Collector
communication is disrupted for some reason, the user information with the Sensor might not be
current. As a redundant measure, the Sensor is designed to passively snoop Kerberos traffic passing
through its monitoring ports. This typically happens when users attempt to log on using their AD
credentials. The Sensor sends the user details from the snooped Kerberos traffic to the Manager. Then
McAfee Network Security Platform 8.1
IPS Administration Guide
515
20
Firewall policies
User-based access rules
the Manager communicates with the AD servers to validate the user credentials. This Kerberos-based
detection of user details is independent of the updates from McAfee Logon Collector. The updates from
McAfee Logon Collector and the user details through Kerberos are used to update the same set of
data. When you create user-based rules, only the user names and user groups received through
updates from McAfee Logon Collector are displayed. The user names derived through Kerberos
snooping are not displayed.
In case of Sensor failover, the Sensor that detected the Kerberos traffic sends the details to the
Manager. It also sends the details to its peer Sensor. The peer Sensor sends the same details to the
Manager. The Manager verifies with the AD servers and responds to both the Sensors separately. In
case of MDR pair, the process is same but only the active Manager is involved.
How the Sensor evaluates user-based access rules
1
Consider an access rule that has only AD user names mentioned. To evaluate the traffic against this
rule, the Sensor takes the source IP address in the packet and checks it against the IP-to-user
mapping list that it has. This way, the Sensor determines the currently logged on user for that IP
address. If this matches with any of the user names mentioned in the rule, then it is a match with
respect to the source user. If not the Sensor proceeds to check the next rule.
2
Consider that you have mentioned only user groups in the rule. As explained above, the Sensor
first determines the currently logged on user. Then it checks this user name against the
user-to-user group mapping that it has. If any of the user group of this user matches with any of
the user groups in the rule, it is a match with respect to source user. If not the Sensor proceeds to
the next rule.
3
In case of both user names and user groups in the rule, the Sensor checks for the user and user
group in the same order that you have configured.
Require Authentication access rule and how it works
You can create an advanced Firewall access rule with the Response set as Require Authentication. When you
implement such a rule, the Sensor ensures that the corresponding users have valid AD logon
credentials.
A Require Authentication access rule is effective only when the monitoring ports are inline. These rules are
relevant only for HTTP traffic and becomes effective only when configured on top of all the rules in the
Access Rules tab while creating an internal firewall policy
516
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
User-based access rules
20
If you have created a require-authentication access rule, the Sensor ensures AD authentication in the
following ways:
1
As discussed in the earlier sections, when users log on to your network, the Sensor receives the
user details through the Manager. So, if the Sensor has an IP-to-user mapping, it indicates that the
user has been already authenticated by the AD server. So, the Sensor proceeds to evaluate the rest
of the rules.
2
If the Sensor does not have a user bound to the IP address in the detected HTTP traffic, it redirects
the user to the Guest Portal. This is the Web portal hosted on the Sensor for explicitly determining
the identity of users based on their AD credentials.
The Sensor sends the logon credentials that the user entered in the Guest Portal to the Manager.
The Manager checks if it already has the AD details of the user. If yes, it forwards the details to the
Sensor. If not, it verifies the user credentials with the configured list of AD servers. The Manager
notifies whether the credentials are valid or not to the Sensor. The Manager provides the IP-to-user
and user-to-user group mappings to the Sensor.
In case of Sensor failover, the Sensor that detected the HTTP traffic redirects the user to its Guest
Portal. It sends the AD details to the Manager. The Manager verifies with the AD servers and
responds to the Sensor. If the authentication is successful, the Sensor sends the details to its peer
Sensor. In case of an MDR pair, the process is same but only the active Manager is involved.
The following are the parameters allowed in a require-authentication access rule:
•
You must select the default HTTP Service rule object as the Application. You cannot select any other
rule object for Application. Even the default HTTP Application rule object or a custom HTTP Service
rule object are not valid.
•
The Source User must be set to Any.
•
Select the Response as Require Authentication.
For all other parameters, you can specify the values you require. For example, you can specify all your
critical Web servers in the Destination Address field. So, the Sensor ensures that all users accessing these
Web servers have valid AD credentials.
Purpose of require-authentication access rules
Assume that the communication between the Manager and McAfee Logon Collector is down. Now,
consider a user who is physically connecting a Windows host that is already unlocked. In this case, the
Sensor might not have a IP-to-user mapping because the communication with McAfee Logon Collector
is down. Also, the host did not generate any Kerberos traffic since the host is already unlocked.
Because the Sensor does not have the IP-to-user mapping, it might not be able to evaluate and apply
the correct user-based access rule for this user. If you have a require-authentication rule, then the
Sensor will be able to derive the user details even in this case as illustrated by the following example.
Consider the following example rules:
1
Source Address: Any | Source User: Any | Destination Address: Critical Web servers | Application:
HTTP service | Response: Require Authentication.
2
Source Address: Any | Source User: Jane | Destination Address: Critical Web servers | Application:
HTTP service | Response: Scan.
3
Source Address: Any | Source User: John | Destination Address: Critical Web servers | Application:
HTTP service | Response: Deny.
McAfee Network Security Platform 8.1
IPS Administration Guide
517
20
Firewall policies
User-based access rules
Consider that Jane accesses a critical Web server:
1
If the Sensor has the IP-to-user mapping for this traffic, the Sensor proceeds to the second rule. In
this case, only the second rule is considered as a match.
2
If the Sensor does not have the IP-to-user mapping for this traffic, it redirects Jane to its Guest
Portal, where the Jane enters her AD credentials. In this case, the first rule is considered as a
match. The Manager checks if it has the AD details for Jane. If not, it verifies these credentials with
the AD servers and also forwards the details related to Jane to the Sensor. So, the Sensor now has
at least the IP-to-user mapping for Jane.
3
Jane retries to access a critical Web server. This time, since the Sensor has the IP-to-user mapping,
it proceeds to the second rule. The second rule matches and the Sensor forwards the traffic for IPS
inspection.
Requirements for require-authentication access rules
In addition to the requirements in High-level steps for implementing user-based Firewall and QoS
rules, the following are required for a required-authentication access rule to work:
•
You have deployed the required Sensor monitoring ports in inline mode. Required-authentication
access rule is not effective in SPAN or tap mode.
•
You must specify an IP address to the monitoring port pair to redirect users to the Guest Portal.
•
You must specify the AD servers and trusted Domain Controllers that the Manager should check
with to verify the AD credentials entered in the Guest Portal.
•
Enable the Guest Portal settings through the Manager.
Considerations for access rules
The following are the considerations for access rules:
518
•
You can create user-based access rules only in advanced Firewall policies.
•
You integrate the Manager only with one instance of McAfee Logon Collector. Integration with a
redundant McAfee Logon Collector setup is not supported.
•
You cannot add, modify, or delete a user name or user group in the Manager.
•
The Sensor does not communicate with the AD servers or McAfee Logon Collector directly.
•
You can specify only user and user group as the criteria. No other AD properties are supported.
•
Only IPv4 hosts are supported. A rule will not match if the user logs on from an IPv6 host.
•
The following are the limits for user data:
•
Up to 100,000 IP-to-user mappings
•
Up to 75,000 user names
•
Up to 10,000 groups for the M-series and 2,000 groups for the NS-series and Virtual IPS
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
User-based access rules
•
20
Maximum user-based rule objects that you can use in the Firewall policies per Sensor model is as
follows:
Sensor model
Maximum user-based rule objects
M-8000
2500
M-8030, M-6050
1250
M-6030, M-4050, M-4030, M-3050
1000
M-3030, M-2950, M-2850, M-2750
750
M-1450, M-1250
500
•
In a Firewall access rule or QoS rule, you cannot specify an IPv4-based rule object for one field and
IPv6-based rule objects for other applicable fields. For example, if you select an IPv6-based rule
object in the Source field, then you cannot specify IPv4-based rule objects for Destination or Source User
fields. For this example, you can specify only an IPv6-based rule object or any as the value for
Destination and any for Source User. Recall that User and User Group rule objects are considered as
IPv4-based rule objects because McAfee Logon Collector 2.0 does not collect user information from
IPv6 hosts. Similarly, Country and Host DNS Name are also IPv4-based rule objects.
•
User log off is not monitored.
•
User or user group deletion is not monitored.
•
When you add new users in the AD, modify user groups, or delete user groups you must run the
MLC Refresh Users server task manually in McAfee Logon Collector. Then the current data from the
AD is available in the Manager.
•
Guest Portal user timeout, by default, is 8 hours.
Troubleshooting user-based access rules
The following are some points that you can consider to troubleshoot issues related to user-based
access rules:
•
Make sure that above your user-based access rules, there are rules that allow DNS, DHCP, and AD
traffic to the corresponding servers.
•
If a user-based rule is not working as expected, change the Source User to any and see if the rule is
working fine.
•
If you are unable to view the users or user groups in the Firewall Policy page, check the
communication between the Manager and the McAfee Logon Collector.
•
CLI commands related to user-based access rules:
•
•
show userInfo stats: Displays the number of full (bulk) updates and incremental updates to
the Sensor. Also, displays the number of users, user groups, and host IP addresses currently
present in the Sensor.
The Manager raises a fault message for the following conditions :
•
The Manager is unable to contact McAfee Logon Collector.
•
The number of IPs to users mapping has exceed 100,000.
•
The number of users has exceeded 75,000.
•
The bulk update from the Manager to the Sensor is more than 25 MB in size. In this case, the
fault is raised and the Manager aborts the update.
•
When user groups exceeds 10,000 in an M-series model and 2,000 in an NS-series or Virtual
IPS.
McAfee Network Security Platform 8.1
IPS Administration Guide
519
20
Firewall policies
Configure Firewall policies
When the user groups limit exceed the specified values, the following faults are raised:
•
AD user groups size exceeded
•
MLC IP-User mapping/ User count exceeds limit
•
MLC Group Size fault
For more information on these faults, see the topic Manager faults, chapter System Fault
Messages in the McAfee Network Security Platform Troubleshooting Guide.
Configure Firewall policies
To configure the Firewall feature, first create the required rule objects, define the Firewall policy, and
then define the access rules for that policy. After you create the Firewall policy, you can assign it to the
required Sensor resource. This section provides the step-by-step information on how to configure the
Firewall feature.
Manage rule objects
You use rule objects to define your Firewall, QoS, and Quarantine Zone access rules.
Table 20-2 Option definitions
Option
Definition
Rule object Table
Displays the rule objects according to the filter criteria. Click a column heading to
sort the table in ascending or descending order.
• Name —Indicates the name of the rule objects.
• Description —Indicates the description of the rule object.
• Type —Indicates the rule object type.
• Owner Domain —Indicates the admin domain to which a rule object belongs. All the
default rule objects belong to the root admin domain.
• Visibility Indicates the visibility settings of settings to the domains, whether it is
visible only to th owner domain or to both owner and child domains.
• Editable here — Yes indicates that the rule object is a custom rule object belonging to
the current admin domain. If it is No, you cannot edit the rule object because it is
a default rule object or a custom rule object defined at a parent admin domain.
Object Type
Filters rule objects in the list.
• Default Object Only — McAfee pre-defined these rule objects. For example, the
Application and Country are default rule objects. You cannot define these rule
objects.
• Custom Object Only — You need to define these rule objects. For example, you need
to define the Host DNS Name rule object.
• Custom and Default Object Only —when selected, it displays both the predefined and
user defined rule objects. For example, IPv4 Network Rule Object has the 3
reserved private networks pre-defined, but you can create your Network rule
objects as well.
520
Rule Object Type
Select the rule object type that you want to view.
Search
Type your search criteria in the field to find rule objects with matching elements. For
example, type to list the rule objects containing google as part of their names.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Configure Firewall policies
20
Table 20-2 Option definitions (continued)
Option
Definition
icon
icon
icon
To view or edit
a rule object
Creates a custom rule object.
Clones a rule object. You cannot clone default rule objects other than the IPv4
network rule objects.
Deletes a custom rule object belonging to the current admin domain.
Double-click the rule object belonging to the current admin domain.
In the Manager, each rule object type has an associated icon for easy identification. The following table
lists the rule objects and the corresponding icons.
Table 20-3 Rule object icons
Icon
Rule Object
Application
Application Group
Application on Custom Port
Country (displays the country's flag. So, the icon varies for each country)
Finite Time Period
Host DNS Name , IPv4 Endpoint, and IPv6 Endpoint
IPv4 Address Range and IPv6 Address Range
IPv4 Network and IPv6 Network
Network Group
Recurring Time Period
Recurring Time Period Group
Service
Service Group and Service Range (Service Range is applicable only to QoS policies) .
You cannot clone a default rule object except for Network. You cannot edit or delete any default rule
object. You can edit or delete custom rule objects only at the admin domain where they were created.
Notes on IPv4 and IPv6 rule objects
For Firewall and QoS, IPv6 addresses are supported for the following rule objects:
•
Host
•
Address range
•
Network
McAfee Network Security Platform 8.1
IPS Administration Guide
521
20
Firewall policies
Configure Firewall policies
The default Service rule object for ICMPv6 is also now available.
•
You use the above-listed, IPv6-based rule objects to create a Network Group rule object. However,
you cannot use a combination of IPv4 and IPv6 based rule objects in one Network Group rule
object.
•
In a Firewall access rule or QoS rule, you cannot specify an IPv4-based rule object for one field and
IPv6-based rule objects for other applicable fields. For example, if you select an IPv6-based rule
object in the Source field, then you cannot specify IPv4-based rule objects for Destination or Source User
fields. For this example, you can specify only an IPv6-based rule object or any as the value for
Destination and any for Source User. Recall that User and User Group rule objects are considered as
IPv4 based rule objects because McAfee Logon Collector 2.0 does not collect user information from
IPv6 hosts. Similarly, Country and Host DNS Name are also IPv4-based rule objects.
The following table classifies IPv4 and IPv6 rule objects:
Type Rule objects
IPv4
IPv4 Endpoint, Host DNS Name, IPv4 Address Range, IPv4 Network, User, User Group,
Country.
IPv6
IPv6 Endpoint, IPv6 Address Range, IPv6 Network.
You configure user-based Firewall access rules using the user and user group rule objects. It is
important to note the following regarding these rule objects:
•
You cannot create, modify, or delete the User or User Group rule objects. The Manager manages
these rule objects according to the updates from McAfee Logon Collector.
•
You can view these rule objects only in the Access Rules tab of the Firewall policies page. You cannot
view these rule objects in the Rule Objects page.
•
The user names verified through Kerberos snooping or the Sensor's Guest Portal are not displayed
in the Manager.
View the rule objects
You can view existing rule objects in a selected domain.
For a rule object to be listed, it must meet one of these conditions:
•
It is a default rule object.
•
It is created at a parent admin domain, but it is set to be visible to the child admin domains.
•
The rule object was created at the current admin domain.
Task
522
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | Objects | Rule Objects or Intrusion Prevention | Exceptions | Rule Objects.
McAfee Network Security Platform 8.1
IPS Administration Guide
Firewall policies
Configure Firewall policies
20
Rule Objects for the selected admin domain are listed.
•
To locate specific rule objects, use the search function.
•
To view limited details of a rule object, point to the object. To view complete details, select and
double-click the rule object.
Figure 20-4 Viewing Rule Objects
Add a rule object
You can create custom rule objects to use for Firewall, QoS, and Quarantine Zone rules. Generally, you
can add up to 10 items in a rule object. For example, in a Host DNS Name rule object you can add up
to 10 DNS Host Names.
Task
1
Click the Policy tab.
2
From the Domain drop-down list, select the domain you want to work in.
3
Select Intrusion Prevention | Objects | Rule Objects or Intrusion Prevention | Exceptions | Rule Objects.
Rule Objects for the selected admin domain are listed.
McAfee Network Security Platform 8.1
IPS Administration Guide
523
20
Firewall policies
Configure Firewall policies
4
Click
. The Object Details window is displayed.
Figure 20-5 Selecting Criticality for each of your assets
Item
Description
1
Options that are common to all rule objects
2
Options that are specific to the selected rule object.
The following table describes the options that are common to all rule objects.
Option
Definition
Name
Enter a unique name to easily identify the rule object.
Description Enter the description for the rule object.
Type
From the drop-down