Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Revision E
COPYRIGHT
Copyright 2015 McAfee, Inc., 2821 Mission College Boulevard, Santa Clara, CA 95054, 1.888.847.8766, www.intelsecurity.com
TRADEMARK ATTRIBUTIONS
Intel and the Intel logo are registered trademarks of the Intel Corporation in the US and/or other countries. McAfee and the McAfee logo, McAfee Active
Protection, McAfee DeepSAFE, ePolicy Orchestrator, McAfee ePO, McAfee EMM, McAfee Evader, Foundscore, Foundstone, Global Threat Intelligence,
McAfee LiveSafe, Policy Lab, McAfee QuickClean, Safe Eyes, McAfee SECURE, McAfee Shredder, SiteAdvisor, McAfee Stinger, McAfee TechMaster, McAfee
Total Protection, TrustedSource, VirusScan are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the US and other countries.
Other marks and brands may be claimed as the property of others.
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.
Contents
Preface
5
5
5
6
Introduction
Pre-installation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Pre-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Post-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disable non-required services . . . . . . . . . . . . . . . . . . . . . . . . . .
Set system policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set user policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set the desktop firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configure audit events . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
12
12
12
13
13
14
15
17
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
18
Response management
19
19
20
21
23
25
10
27
11
29
29
Contents
SSL
SSL
SSL
SSL
SSL
12
30
31
32
33
33
35
. . . . . . . . . . . . . . . . . . . . . .
NS-series Sensors . . . . . . . . . . . . . . .
Virtual IPS Sensor . . . . . . . . . . . . . . .
M-series Sensors . . . . . . . . . . . . . . .
I-series Sensors . . . . . . . . . . . . . . . .
35
36
37
37
37
13
39
14
45
15
47
16
51
17
55
18
57
Index
59
Preface
This guide provides the information you need to configure, use, and maintain your McAfee product.
Contents
About this guide
Find product documentation
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
Bold
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
Preface
Find product documentation
Enter a product, select a version, then click Search to display a list of documents.
Introduction
Pre-installation checklist
There are some important tasks that you should consider before McAfee Network Security Manager
[formerly McAfee IntruShield Security Manager] software installation. For more information, see
Planning for installation, McAfee Network Security Platform Troubleshooting Guide.
Introduction
Pre-installation checklist
It is a common practice to physically cable the monitoring ports, only after the McAfee Network
Security Sensor (Sensor) has been fully configured.
In other words, most administrators cable the console and management ports, use those connections
to configure the solution, and only physically introduce the Sensor into the scanning process once the
proper scanning policies are in place, the monitoring ports have been configured, the latest signature
set has been downloaded, and so on.
Also, in the most security-conscious environments, or those with congestion problems, a private
network is often used to connect the Sensor management ports to the McAfee Network Security
Manager (Manager). This is another best practice in terms of cabling the Sensors.
10
Implementation of Manager varies from environment to environment. The Manager's physical and
logical position in the network influences specific remote access and firewall configuration
requirements. The following best practices on managing configurable features on Manager impacts the
security of Manager.
These steps are applicable to Windows Server 2008 and Windows Server 2012 editions.
Contents
Pre-installation
Installation
Post-installation
Pre-installation
Use a dedicated machine for the Manager server and then install Manager and the embedded MySQL
database. Other than the host-based firewall, no other software should be installed on the server.
Before installation of Manager do the following:
If the hard disk is old, use fdisk (a command line utility) to remove all partitions and create new
partitions.
Installation
Installation of Manager should be performed as follows:
11
Post-installation
After installation of Manager perform the following installations:
Install the latest Windows Server patches, service packs, and hot fixes from Microsoft.
Minimize the number of Windows roles and features that are installed.
DHCP Client
FTP
Print spooler
Remote registry
Server
Telephony service.
Enable these services only if it is absolutely required.
12
Implement the System key and strong encryption of the password database by running
SYSKEY.EXE
Disable Posix
Disable autorun
Port Description
Communication
80
HTTP port
Client to Manager
443
HTTPS
Client to Manager
Manager to Sensor
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Sensor to Manager
Client to Manager
When email notification or SNMP forwarding is configured on Manager and there is firewall between
Manager and SNMP Server, ensure that the following ports are allowed through firewall.
Port
Description
Communication
25
SMTP port
162
SNMP forwarding
If you have McAfee ePO integration configured on Manager, and there is firewall between Manager
and the McAfee ePO Server, ensure the following port is also allowed through firewall.
Port
Description
Communication
8443
13
14
When you consider large McAfee Network Security Sensor (Sensor) deployments, (where the number
of Sensors deployed range from 36 to 100) there are some important tasks which should be
considered, before deployment.
McAfee recommends that you have a good understanding on the best techniques required to
accomplish these tasks in your deployment scenario, prior to the deployment.
Concurrent Signature Set and Sensor Software downloads In 6.0.7.x and above, the
Manager provides an option for parallel processing of Sensor software and signature set updates.
In earlier releases of 6.0, when multiple Sensors are configured to your Manager, any software
update on the Sensors had to be performed individually. If you are using 5.1, then note that this
option is available on Manager version 5.1.17.2 and above.
This enhancement is applicable only for Sensor updates in the parent domain. The Sensor updates
in the child admin domain is performed in the same method as the earlier releases.
Sensor Software Updates All Sensor software updates do require a reboot. A reboot can take
up to 5 minutes. You can schedule this process though you can't reboot the Sensor automatically.
But any update from the Manager Server causes the process to take place sequentially, one Sensor
at-a-time. You can instead use the TFTP method for updating the Sensor image, which helps you to
load concurrent images on the Sensor via the Sensor's CLI, at a much faster rate.
For more information, see Upgrading Sensor software via a TFTP server, McAfee Network Security
Platform CLI Guide.
Central Manager deployment If you have a large Sensor deployment of 200 Sensors for
example, which are deployed across various geographic locations, then consider using a Central
Manager at your organization's headquarters and deploy a dedicated Manager for each region. Each
Manager will then handle the daily device operations for all Sensors configured to it. Note that
when you use a Central Manager, your regional/local Managers can add their own region-specific
rules, but cannot modify any configuration established by the Central Manager. Configuration
updates to the Sensors must be applied through the local Managers. See McAfee Network Security
Platform Manager Administration Guide for details.
Usability Depending on the number of VIDS and Admin Domains defined in your deployment,
the Manager Resource Tree can become very crowded, which makes it difficult to locate the
resource you require at any point of time. It can also lead to confusion if you have not provided
unique, recognizable names for your Sensors and any VIDS you create. Note that the resource
names appear both in the Resource Tree of the Manager as well as in Alert data and Reports. Your
VIDS names should also be clear and easy for everyone maintaining the network to recognize at a
glance. For example, compare a worldwide deployment where Sensors are named "4010-1"
through "4010-25" as opposed to "UK-London-sens1," "India-Bangalore-sens1," and so on.
Alert Traffic Take note of the volume of alerting in your Sensors. Depending on the policies
deployed on your system, there is potential to starve Manager resources since the resulting alerts
are passed to the Manager. As the volume of alerting increases, more data is passed into the
Manager. The Manager can handle short bursts of high alert volume but on an average, the
Manager can handle a total of 1500 alerts per minute from all the Sensors configured to it.
15
Start-up load on the Manager When the Manager starts, establishing connections with all
Sensors can be time consuming as Sensors continue to collect alerts. If the communication with
the Manager is lost, each Sensor must pass its alert data to the Manager when connectivity is
re-established. So, it is required to account for the start-up load on the Manager.
Concurrent processes Be aware of the time periods in which your scheduled processes (such
as database backup or report generation) occur, and try not to attempt other tasks during that time
period, as this can lead to process locking. This includes having many users logged into the system
simultaneously.
Contents
Staging Sensors prior to deployment
Recommendations for large Sensor deployment
16
Spend time creating effective policies before actual deployment. Availability of more information
makes the tuning process easier. But policies like the McAfee Network Security Platform provided
All-Inclusive policy can overwhelm you with data, if every Sensor in a large deployment is running
it without any customization.
Stagger your Sensor deployment in phases. As each new batch of Sensors provides you with more
data points, you can tune your policies more effectively, and become more aggressive in the
number of Sensors you deploy in the next phase.
McAfee supports the following types of passive and active fail-open kits:
Fail-open kits can be deployed in production networks for the following reasons:
Reduce the network downtime to seconds during any Sensor reboot or Sensor failure
Bypass the traffic when troubleshooting network issues. This will help you identify or eliminate the
Sensor as the cause of network issues
In the passive fail-open kit, if the Sensor goes down, the link has to be renegotiated again between
the peer devices and this causes the link to go down for some time. In case of an active fail-open kit,
a physical link will be established between the active fail-open kit and the two peer devices even when
the Sensor is active. There would not be any link flap even when the Sensor goes down. McAfee
recommends deploying active fail-open kits for protection of mission critical networks.
For Virtual IPS Sensors, only 10/100/1000 Copper Active Fail-Open Bypass Kit and 10/100/1000
Copper Active Fail-Open Bypass Kit with SNMP monitoring are supported. For more information, see
Virtual IPS Sensor deployment section in the IPS Administration Guide.
Passive Fail-open
In passive fail-open kits, during normal Sensor in-line, fail-open operation, the Fail-Open Controller or
built-in Control port (depending on which controls the Bypass Switch) supplies power and a heartbeat
signal to the Bypass Switch.
If this signal is not presented within its programmed interval, the Fail-Open Bypass Switch removes
the Sensor from the data path, and moves into bypass mode, providing continuous data flow with little
network interruption. While the Sensor is in bypass mode, traffic passes directly through the switch,
bypassing the Sensor. When normal Sensor operation resumes, you may or may not need to manually
re-enable the monitoring ports from the Manager interface, depending on the activity leading up to the
Sensor's failure.
Active Fail-open
17
In case of active fail-open kits, during normal Sensor in-line fail-open operation, the built-in
monitoring sends a heartbeat signal (1 every second) to the Bypass Switch. If the Sensor does not
receive 3 heart beat signals within its programmed interval, the Fail-Open Bypass Switch removes the
Sensor from the data path, and moves it into the bypass mode, providing continuous data flow.
When the Bypass Switch loses power, traffic continues to flow through the network link, but is no
longer routed through the Bypass Switch. This allows network devices to be removed and replaced
without network downtime. Once power is restored to the Bypass Switch, network traffic is seamlessly
diverted to the monitoring device, allowing it to resume its critical functions.
Considerations
This section discusses the generic requirements and notes that you need to consider with respect to
active fail-open kits:
The currently supported active fail-open kits are not plug and play devices. Initial configuration/
setup is required before you begin.
The following default options are fixed in McAfee active fail-open kits and cannot be changed:
LFD is set to On
18
The management port on the active fail-open bypass kits cannot be configured.
The parameters for the monitoring port must be set to Auto-Negotiate based on the speed, that is,
10/100/1000 Mbps. McAfee recommends that you set the Speed to 100 Mbps full Duplex with
Auto-Negotiate enabled to improve performance.
Unlike passive fail-open kits, an active fail-open kit moves into the bypass mode only when it does
not receive the heart beat signals within its programmed interval. When the Sensor monitoring port
is manually disabled or the cable is pulled out for example, the Manager displays the port status as
AUK (Active Unknown) under Device List / Sensor_Name > Physical Sensor > Port Settings page.
If you are planning to use the 10/100/1000 copper active fail-open kit with SNMP monitoring, then
note that
Network Security Platform currently supports only SNMP v1 on active fail-open kits.
You can configure only a single SNMP Manager. The option to configure a secondary SNMP Manager
is currently not available.
The active fail-open kits do not provide any CLI option to view the serial and model numbers of the
kits.
If your network architecture is such that it requires you to remotely manage the active fail-open
kits in your deployment, then you can consider one of the following options:
Use a terminal server to connect to the system console and then connect using a remote login
[interoperability issues might be seen while using UPLOGIX Terminal Server]
All Network Security Sensors (Sensors) on initial deployment, have the 'Default Inline IPS' policy
loaded on all interfaces. McAfee recommends that you use the default inline IPS policy as a starting
point, then customize the policies based on your organization's requirements. The customized policies
can be either cloned versions of the default pre-configured policies or custom-built policies that
employ custom rule sets. An appropriately tuned policy will reduce false positives.
Though each network environment has unique characteristics, the following best practices can make
tuning more efficient and effective.
As you interact with Network Security Platform policies, you encounter the term "attack", not
"signature." Network Security Platform defines an attack as being comprised of one or more signatures,
thresholds, anomaly profiles, or correlation rules, where each method is used to detect an attempt to
exploit a particular vulnerability in a system. These signatures and checks may contain very specific
means for identifying a specific known exploit of the vulnerability, or more generic detection methods
that aid in detecting unknown exploits for the vulnerability.
Contents
Analyzing high-volume attacks
Managing exception objects
Learning profiles in DoS attacks
19
For instance, an SMS server may be generating the alert Netbios: Copy Executable file attempt during the
legitimate transfer of login scripts. Rather than disable the alert altogether, and cancel the possibility
of finding a real attack of this nature, we recommend that you create an exception object for the SMS
server and apply it to the attack.
Every exception object created is globally stored, so that the filter can be applied to any Exploit or
Reconnaissance attack.
It is also a best practice to document all your tuning activities. The Report section can be used to
assist the documentation process. The IPS Sensor configuration report will deliver reports that list
exception objects that have been applied and attacks that have been otherwise customized.
For more information, see Managing Exception Objects and Attack Responses, McAfee Network Security
Platform IPS Administration Guide.
20
Response management
When McAfee Network Security Sensor (Sensor) detects an activity which violates a configured
security policy, a preset response from the Sensor is integral to the protection or prevention process.
Proper configuration of responses is crucial to maintaining effective protection. Critical attacks like
buffer overflows and DoS attacks require responses in real time, while scans and probes can be logged
and researched to determine compromise potential and the source of the attack.
Developing a system of actions, alerts, and logs based on specific attacks or attack parameters (such
as severity) is recommended for effective network security. For example, since McAfee Network
Security Platform can be customized to protect any zone in a network, knowing what needs to be
protected can help to determine the response type.
If the Sensor is monitoring the network outside of the firewall in inline mode, preventing DoS attacks
and attacks against the firewall is crucial. Other suspicious traffic intended for the internal network,
such as scans and low-impact well-known exploits, are best logged and analyzed as the impact is not
immediate. In this case, a better understanding of the potential attack purpose can be determined.
Thus, if you are monitoring outside of a firewall in in-line mode, it is important not to set the policies
and responses so fine that they disrupt the flow of traffic and slow down the system.
Remember that response actions are decoupled from alerting. Pay particular attention to this with the
Recommended For Blocking (RFB) category of attacks, lest you enable blocking for an attack, but
disable alerting, causing the attack to be blocked without your knowledge.
When there are multiple attempts to login to a specific web server from a client, the Sensor detects a
reconnaissance Brute force attack (Attack ID 0x40256b00) and raises an alert. Brute force attacks are
used by programs, such as password crackers, to try many different passwords in order to guess the
correct one. The alerts raised are threshold based. The Sensor may generate an alert even in
scenarios, where a legitimate user keeps on retrying to login to the web server simply because he has
forgotten his password. Instances of someone mistyping a password or username on the login are also
common. In such cases, valid traffic flow would be blocked or subject to unnecessary responses from
the Sensor, leading to a false positive. Consequently, the traffic might be dropped.
When such alerts are seen in high volume, there may be multiple reasons for it, like, a dictionary
attack against the web server, or network monitoring systems (like WebSense) not updated with a
user password change, and so on.
McAfee Network Security Platform recommends that while configuring a Reconnaissance policy, you
to edit and set optimum threshold values to suit your particular environment. This avoids unnecessary
responses from the Sensor and hindrance to the traffic flow.
For example, if you have a web-server farm behind the Sensor so there are more HTTP logins seen on
this segment, in such a scenario you require to set higher thresholds. The default values are good for
most environments.
21
Response management
Sensor response actions
Dropping Alert Packets Only works in in-line mode. Will drop a detected attack packet and all
subsequent packets in the same flow.
Quarantine Sensor will quarantine or remediate a host as per the configurations in McAfee Network
Security Manager and the Sensor monitoring ports. Quarantine can be enabled per attack in the
Policy Editors.
For more information, see McAfee Network Security Platform IPS Administration Guide.
22
A rule set is configured based on attack category, operating system, protocol, application, severity,
and benign trigger probability options. Each rule in a set is either an include rule or an exclude rule.
An include rule (which should always start a rule set) is a set of parameters that encompass a broad
range of well-known attacks for detection. An exclude rule removes elements from the include rule in
order to focus the policy's rule set.
Proper creation of rule sets is essential for eliminating false positives and ensuring maximum
protection on your network. These best practices can assist while creating rules sets in the McAfee
Network Security Manager.
General-to-specific rule creation The first method is general-to-specific. Start with an include
rule that covers a broad range of operating systems, applications and protocols. After this, create
one or more exclude rules to strip away specific operating systems, protocols, et cetera, thus
focusing the rule set on the environment where it will be enforced. For example, start with an
include rule for all Exploit category attacks. Follow this with multiple exclusion rules that strip away
protocols, applications, severities, et cetera, that are rarely or never seen in a zone of your
network.
Collaborative rule creation The second method is collaboration: Create multiple include rules
within one rule set for each category, operating systems, et cetera, combination that needs to be
detected. Each criterion must be matched in order for an alert to be triggered. For example, create
the first rule in the set with the Exploit category, Unix as the OS, Sendmail as the application, and
SMTP as the protocol. Next, create another include rule for Exploit, Windows 2000, WindMail, and
so forth in the same manner. Each include rule added, broadens the scope of the detection.
For more information, see Managing Rule Sets, McAfee Network Security Platform IPS
Administration Guide.
23
24
You cannot set explicit access rules for protocols that negotiate ports dynamically, with the
exception of FTP, TFTP, and RPC services. Protocols such as H.323 and Netmeeting, which negotiate
the data channel separately from the control channel, or negotiate ports that do not follow a
standard, are not supported. However, you can explicitly deny these protocol instances by denying
the fixed control port. However, you can configure access rules to explicitly deny these protocol
instances by denying the fixed control port.
For RPC services, you can configure explicit permit and deny rules for RPC as a whole, but not its
constituents, such as statd and mountd.
Protocols or services, such as instant messaging and peer-to-peer communication, that use
dynamic ports, are not supported.
An alternative option for denying protocols that use dynamic ports is to configure IDS policies to
drop the attacks that are detected in such transmissions. Network Security Platform detects use of
and attacks in such programs as Yahoo Messenger, KaZaA, IRC, and so on.
There is a limit on the number of access rules that can be supported by various Sensor models.
For more information, see McAfee Network Security Platform IPS Administration Guide
25
26
10
Traffic that uses a different path for the request vs. response is termed as asymmetric traffic. There
are chances of having asymmetric traffic within a network, when networks increase in size.
If there are chances of asymmetric traffic in your network, consider the following options:
Implement a port clustering configuration for asymmetric traffic. Port clustering [referred to as
Interface groups in the Manager] enables multiple ports on a single Sensor to be grouped together
for effective traffic monitoring. Asymmetric networks are common in load balancing and active/
passive configurations, and a complete transmission may be received on one segment, but depart
on another. Thus keeping state of asymmetric transmissions is essential for successfully monitoring
the traffic. Interface groups normalize the impact of traffic flows split across multiple interfaces,
thus maintaining state to avoid information loss.
Place an IPS Sensor each on the request and the response path of the asymmetric traffic and
create a failover pair to sync up the traffic flow between the two Sensors.
If you are using a failover pair to monitor asymmetric traffic where the TCP traffic is going through
two geographically different data centers, connect the Sensors using dark fiber. In this option, both
the Sensors will have full state.
When the distance between the two IPS Sensors is such that a failover pair cannot be created,
consider enabling Stateless Inspection. In Stateless Inspection, the Sensor detects attacks without
requiring a valid TCP state. This option should be used only when Sensors are placed in a network
where the Sensors do not see all packets of a TCP flow like in an asymmetric network
configuration.
When Stateless Inspection is enabled: - ACLs and syn cookie protection cannot be enabled. - HTTP
redirection to the Remediation Portal may or may not work depending on your network deployment
scenario for example, in a setup where SYN+ACK packets cannot be sent from the Sensor to the
client
The diagram below explains about HTTP traffic flow in an asymmetric network between User A and the
University Admin server. The outgoing connection flow from User A is through Switch 1, Switch 2,
Network Security Sensor 1, Router 1, Internet Service Provider 1, to the Internet connection. The
return path for the packet however, is through Internet Service Provider 2, Router 2 etc. If traffic flows
by the Sensor in an asymmetric manner as described above, all packets of a TCP flow are not visible
to a single Sensor.
In such a scenario, if Stateless Inspection is enabled, the Sensor will inspect packets without having
the valid state for the TCP connection. Consequently, it might generate false positives that is, when a
single communication flow is divided across paths, each interface will receive and analyze part of the
conversation and therefore be susceptible to false positives and false negatives.
27
10
When you enable Stateless Inspection, there are chances of false positives, and the detection accuracy
will be lower compared to when the Sensor sees all traffic. McAfee recommends that you use this
feature only when network configuration does not allow the Sensor to be placed in locations where it
could see all traffic.
28
11
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 Exception Objects.
Refer to the following sections for the SSL throughput measurements and test methodologies.
SSL decryption feature is not supported on IPS-VM600 and IPS-VM100.
Contents
SSL
SSL
SSL
SSL
SSL
SSL
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
128-bit ARC4
NS9300
1024 bit key length
44000
30800
SSL Throughput
20 Gbps
12 Gbps
22000
15400
SSL Throughput
10 Gbps
6 Gbps
NS9200
NS9100
29
11
17000
13600
SSL Throughput
8 Gbps
5.5 Gbps
12000
12000
SSL Throughput
5 Gbps
5 Gbps
6900
6900
SSL Throughput
3 Gbps
3 Gbps
3500
3500
SSL Throughput
1.5 Gbps
1.5 Gbps
NS7300
NS7200
NS7100
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
128-bit ARC4
NS9300
1024 bit key length
9200
9200
SSL Throughput
4 Gbps
4 Gbps
36 Gbps
36 Gbps
Total Throughput
40 Gbps
40 Gbps
4600
4600
SSL Throughput
2 Gbps
2 Gbps
18 Gbps
18 Gbps
Total Throughput
20 Gbps
20 Gbps
NS9200
NS9100
30
11
2300
2300
SSL Throughput
1 Gbps
1 Gbps
9 Gbps
9 Gbps
Total Throughput
10 Gbps
10 Gbps
2500
2500
SSL Throughput
1 Gbps
1 Gbps
4 Gbps
4 Gbps
Total Throughput
5 Gbps
5 Gbps
2500
2500
SSL Throughput
1 Gbps
1 Gbps
2 Gbps
2 Gbps
Total Throughput
3 Gbps
3 Gbps
2500
2500
SSL Throughput
1 Gbps
1 Gbps
0.5 Gbps
0.5 Gbps
Total Throughput
1.5 Gbps
1.5 Gbps
NS7300
NS7200
NS7100
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
128-bit ARC4
M-8000 M-6050
M-4050
M-3050
M-2950
M-2850
8500
2700
1300
750
550
4500
31
11
5 HTTP 1.1 get page requests per TCP connection with a 5K response each
128-bit ARC4
M-8000
1024 bit key length
1750
1750
SSL Throughput
800 Mbps
700 Mbps
8 Gbps
7.9 Gbps
Total Throughput
8.8 Gbps
8.6 Gbps
880
880
SSL Throughput
440 Mbps
400 Mbps
4 Gbps
3.9 Gbps
Total Throughput
4.4 Gbps
4.3 Gbps
440
440
SSL Throughput
200 Mbps
150 Mbps
2.5 Gbps
2.5 Gbps
Total Throughput
2.7 Gbps
2.6 Gbps
220
220
SSL Throughput
100 Mbps
90 Mbps
1.2 Gbps
1.2 Gbps
Total Throughput
1.3 Gbps
1.1 Gbps
180
180
SSL Throughput
80 Mbps
60 Mbps
900 Mbps
900 Mbps
Total Throughput
980 Mbps
960 Mbps
M-6050
M-4050
M-3050
M-2950
M-2850
32
11
110
110
SSL Throughput
50 Mbps
40Mbps
500 Mbps
500 Mbps
Total Throughput
550 Mbps
540 Mbps
128-bit ARC4
5 HTTP 1.1 get page requests per TCP connection with a 5K response each
I-2700
I-3000
I-4000
I-4010
325
600
800
1200
85 Mbps
155 Mbps
200 Mbps
310 Mbps
65 Mbps
115 Mbps
125 Mbps
250 Mbps
5 HTTP 1.1 get page requests per TCP connection with a 10K response each
I-2700
I-3000
I-4000
I-4010
300
400
800
800
150 Mbps
200 Mbps
400 Mbps
400 Mbps
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
475 Mbps
350 Mbps
Total Throughput
500 Mbps
400 Mbps
200
400
SSL Throughput
50 Mbps
105 Mbps
860 Mbps
475 Mbps
Total Throughput
910 Mbps
580 Mbps
I-3000
33
11
I-4000
Max. SSL Connections / Sec.
400
800
SSL Throughput
100 Mbps
200 Mbps
1550 Mbps
780 Mbps
Total Throughput
1650 Mbps
980 Mbps
I-4010
34
400
800
SSL Throughput
100 Mbps
200 Mbps
1740 Mbps
860 Mbps
Total Throughput
1840 Mbps
1060 Mbps
12
HTTP response processing is disabled by default. You can enable it for each traffic direction on an
interface pair. To minimize the potential performance impact on the McAfee Network Security Sensor
(Sensor), we recommend that you enable HTTP response processing on the minimum number of ports
and in only the required directions to achieve your protection goals.
Some examples of HTTP response processing deployment:
You want to protect a bunch of clients on your internal network - enable HTTP response processing
for inbound traffic only.
You are serving Web content to external clients, and do not wish to serve attacks embedded in
HTTP response traffic - enable HTTP response processing for outbound traffic only.
You want to protect both internal clients as well as the Web content you are serving to external
clients- enable HTTP response processing in both directions.
The test involves only HTTP traffic. Changing the HTTP response processing setting does not
change the Sensor performance for any other protocol. Therefore, changes in aggregate Sensor
performance will depend on the proportion of HTTP traffic to other traffic on the link being
monitored.
The test sends equal HTTP request and response loads in both directions through the Sensor.
Typical real-world deployments do not have equal amounts of HTTP request traffic and response
traffic in both directions through the Sensor. Usually, there is significant amount of request traffic in
one direction and response traffic in the opposite direction. Since HTTP requests are typically <=
1/10th of the response size, the combined HTTP request and response traffic processed by Sensors
in real deployments is typically less than that shown in the tests.
35
12
The test sends HTTP request continuously at maximum load. Real-world networks are typically
loaded, occasionally peaking at maximum capacity, but typically running at significantly lower
throughput. The test results reflect performance at sustained load. When not running at maximum
load, the Sensor can absorb larger bursts without significant impact.
The test environment was created to illustrate the likely worst-case performance impact, expected
to occur in deployments protecting large Web server farms. In these deployments, HTTP response
processing typically provides little value because all HTTP response traffic is sourced from trusted
servers, which do not usually transmit hostile content due to the security measures taken. In these
environments, customers can consider selectively enabling HTTP response processing to better
optimize their network.
The net result of all of these factors is that in typical networks, the impact of enabling HTTP response
processing is not noticed. The exact impact is, of course, dependent on the traffic being inspected and
some environments could see a reduction in performance as significant as the test results indicate.
The factors to take into account include:
size of a response page sent to the client by the sites or applications that are typically accessed.
5 HTTP 1.1 get page requests per TCP connection with a 10K response each sent in one direction,
NS9300
40 Gbps
NS9200
20 Gbps
NS9100
10 Gbps
NS7300
5 Gbps
NS7200
3 Gbps
NS7100
1.5 Gbps
The NS-series performance numbers when HTTP response is disabled will be higher. For example, the
NS9100 performance with HTTP response scanning disabled will be higher than 10 Gbps.
36
12
600 Mbps
100 Mbps
M-8000
10 Gbps
5.4 Gbps
M-6050
5 Gbps
2.8 Gbps
M-4050
3 Gbps
2 Gbps
M-3050
1.5Gbps
1 Gbps
M-2950
1.0 Gbps
850 Mbps
M-2850
600 Mbps
500 Mbps
M-2750
600 Mbps
500 Mbps
M-1450
200 Mbps
200 Mbps
M-1250
100 Mbps
100 Mbps
I-4010
2 Gbps
1 Gbps
I-4000
1.78 Gbps
1 Gbps
I-3000
1 Gbps
680 Mbps
I-2700
550 Mbps
430 Mbps
I-1400
195 Mbps
160 Mbps
I-1200
97 Mbps
75 Mbps
37
12
38
13
Size of a response page sent to the client by the sites or applications that are typically accessed
The test environment used 5 HTTP 1.1 get page requests per TCP connection with a 10 K response,
each sent in one direction.
When Advanced Traffic Inspection is enabled, in a deployment with 90 percent of traffic without
evasions and 10 percent of traffic with evasions, the overall Sensor throughput would further drop
by an additional five percent approximately. For example , if you get 1 Gbps throughput with Layer
7 Data Collection enabled, you would see 950 Mbps if Advanced Traffic Inspection is also enabled.
Observed throughput
NS9300
Disabled
40 Gbps
40 Gbps
Disabled
40 Gbps
40 Gbps
Disabled
40 Gbps
40 Gbps
Disabled
Disabled
20 Gbps
20 Gbps
Disabled
20 Gbps
20 Gbps
NS9200
Disabled
39
13
Table 13-1 NS9x00 performance details with respect to Layer 7 Data Collection (continued)
Sensor Model Layer 7 Data Collection setting HTTP Response
Scanning setting
NS9100
Observed throughput
Disabled
20 Gbps
20 Gbps
Disabled
Disabled
10 Gbps
10 Gbps
Disabled
10 Gbps
10 Gbps
Disabled
10 Gbps
10 Gbps
Table 13-2 NS7x00 performance details with respect to Layer 7 Data Collection
Sensor Model Layer 7 Data Collection setting HTTP Response
Scanning setting
Observed throughput
NS7300
Disabled
7 Gbps
5 Gbps
Disabled
7 Gbps
5 Gbps
Disabled
7 Gbps
5 Gbps
Disabled
Disabled
6 Gbps
3 Gbps
Disabled
6 Gbps
3 Gbps
Disabled
6 Gbps
3 Gbps
Disabled
Disabled
2 Gbps
1.5 Gbps
Disabled
2 Gbps
1.5 Gbps
Disabled
2 Gbps
1.5 Gbps
NS7200
NS7100
40
Disabled
13
Observed throughput
IPS-VM600
Disabled
600 Mbps
500 Mbps
Disabled
600 Mbps
400 Mbps
Disabled
600 Mbps
350 Mbps
Disabled
Disabled
100 Mbps
100 Mbps
Disabled
100 Mbps
90 Mbps
Disabled
100 Mbps
85 Mbps
IPS-VM100
Disabled
HTTP Response
Scanning setting
Observed
throughput
M-8000
Disabled
Disabled
10 Gbps
5.4 Gbps
M-6050
M-4050
9 Gbps
8.7 Gbps
Disabled
Disabled
5 Gbps
2.8 Gbps
4.5 Gbps
4.4 Gbps
Disabled
3 Gbps
Disabled
4.4 Gbps
4.2 Gbps
2.2 Gbps
2.1 Gbps
41
13
Table 13-4 Sensor performance details with respect to Layer 7 Data Collection (continued)
Sensor
model
M-3050
M-2950
M-2850
M-1450
42
HTTP Response
Scanning setting
Observed
throughput
2 Gbps
2.7 Gbps
2.6 Gbps
Disabled
Disabled
1.5 Gbps
1 Gbps
1.3 Gbps
1.2 Gbps
1.4 Gbps
1.3 Gbps
Disabled
Disabled
1 Gbps
850 Mbps
921 Mbps
891 Mbps
Disabled
Disabled
600 Mbps
500 Mbps
540 Mbps
522 Mbps
Disabled
Disabled
200 Mbps
200 Mbps
180 Mbps
174 Mbps
0.7 Gbps
0.6 Gbps
446 Mbps
431 Mbps
261 Mbps
253 Mbps
180 Mbps
174 Mbps
13
Table 13-4 Sensor performance details with respect to Layer 7 Data Collection (continued)
Sensor
model
HTTP Response
Scanning setting
Observed
throughput
M-1250
Disabled
Disabled
100 Mbps
100 Mbps
90 Mbps
87 Mbps
90 Mbps
87 Mbps
43
13
44
14
The following table lists McAfee Network Security Sensor (Sensor) limitations by category and by
Sensor model.
Maximum Type
I-4010
I-4000
I-3000 I-2700
I-1400
I-1200
Aggregate Performance
2 Gbps
2 Gbps
1 Gbps
Concurrent connections
80,000
40,000
25,000
25,000
10,000
6,250
2,000
1,000
100,000
100,000
50,000
25,000
NA
NA
64
64
64
64
NA
NA
1,000
1,000
1,000
100
32
16
3,000
3,000
3,000
300
64
32
254
254
254
254
64
32
Customized attacks
100,000
100,000
100,000 100,000
40,000
20,000
Exception objects
131,072
131,072
131,072 65,535
32,000
20,000
128,000
128,000
128,000 64,000
20,000
16,000
100,000
100,000
50,000
10,000
5,000
750,000
750,000
375,000 187,500
60,000
30,000
DoS Profiles
5,000
5,000
5,000
120
100
64,000
83,000
1,000
100
50
1,000
1,000
25,000
300
400
For more information on computing Effective Access Rules, see IPS Administration Guide.
Note for customized attacks
45
14
Customized attacks are not to be confused with custom attacks. A custom attack is a user-defined
attack definition either in the McAfee's format or the Snort rules language. Whereas a customized
attack is an attack definition (as part of the signature set), for which you modified its default settings.
For example, if the default severity of an attack is 5 and you change it to 7, it is a customized attack.
The signature set push from the Manager to a Sensor fails if the number of customized attacks on the
Sensor exceeds the customized attack limit.
The number of customized attacks can increase due to:
Create a policy.
Set the Outbound rule set to "All-inclusive with Audit rule set".
You see that:
The All-inclusive with Audit rule set has 2204 exploit attacks.
The total number of customized attacks for this policy is 2204 116 = 2038 customized attacks.
46
15
Maximum
Type
M-8000
M-6050
M-4050
M-3050
Aggregate
Performance
10 Gbps
5 Gbps
3 Gbps
1.5 Gbps
1 Gbps
600
Mbps
200
Mbps
100
Mbps
Maximum
throughput
with test
equipment
sending UDP
packet size of
1518 bytes
Up to 20
Gbps
Up to 10
Gbps
Up to 4
Gbps
Up to 2.5
Gbps
Up to
1.5
Gbps
Up to 1
Gbps
Up to
300
Mbps
Up to
150
Mbps
Concurrent
connections
40,000
Connections
established per
sec.
120,000
60,000
36,000
18,000
15,000
10,000
4,000
2,000
100,000
100,000
50,000
50,000
25,000
10,000
5,000
Supported UDP
Flows
375,000
Latency
< 100
micro
seconds
< 100
micro
seconds
< 100
micro
seconds
< 100
micro
seconds
< 100
< 100
< 100
< 100
micro
micro
micro
micro
seconds seconds seconds seconds
400,000
200,000
150,000
75,000
25,000
25,000
NA
NA
256
256
256
256
256
NA
NA
Quarantine
rules per
Sensor- IPv4
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
Quarantine
rules per
Sensor- IPv6
500
500
500
500
500
500
500
500
Quarantine
Zones per
Sensor
50
50
50
50
50
50
50
50
(Average UDP
per packet
Latency)
SSL Flow count
30,000
47
15
Maximum
Type
M-8000
M-6050
M-4050
M-3050
Quarantine
Zone ACLs per
Sensor
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
Virtual
Interfaces
(VIDS) per
Sensor
1,000
1,000
1,000
1,000
1,000
100
32
32
VLAN / CIDR
Blocks per
Sensor
3,000
3,000
3,000
3,000
300
300
64
32
VLAN / CIDR
Blocks per
Interface
254
254
254
254
254
254
64
32
Customized
attacks
100,000
100,000
100,000
100,000
20,000
Exception
objects
262,144
262,144
262,144
262,144
32,768
Number of
attacks with
exception
objects
128,000
128,000
100,000
100,000
20,000
DoS Profiles
5,000
5,000
5,000
5,000
5,000
100
300
120
SYN cookie rate 5,000,000 2,500,000 2,000,000 1,500,000 800,000 600,000 250,000 200,000
(64-byte
packets per
second)
48
Effective
10,000
(Firewall)access
rules
5,000
3,000
3,000
2,000
2,000
1,000
1,000
Firewall rule
objects
70,000
35,000
21,000
21,000
14,000
14,000
7,000
7,000
Firewall DNS
rule objects
2,500
1,250
1,000
1,000
750
750
500
500
Firewall rule
object groups
500
400
300
300
200
200
100
100
Application on
Custom Port
rule objects
1,000
500
500
500
250
250
150
150
Firewall
2,500
user-based rule
objects
1,250
1,000
1,000
750
750
500
500
Firewall user
groups in
access rules
10,000
10,000
10,000
10,000
10,000
10,000
10,000
10,000
15
Maximum
Type
M-8000
M-6050
M-4050
M-3050
Number of
128
whitelist entries
permitted for IP
Reputation
128
128
128
64
256,000
256,000
256,000
Maximum file
size during
packet capture
100 MB
100 MB
100 MB
100 MB
58 MB
58 MB
40 MB
40 MB
Passive device
profile limits
100,000
100,000
50,000
25,000
15,000
15,000
10,000
5,000
Advanced
Malware Maximum
simultaneous
file scan
capacity with
file save
50
50
50
50
32
32
16
16
Advanced
Malware Maximum
simultaneous
file scan
capacity
without file
save
1,024
1,024
1,024
1,024
1,024
1,024
255
255
64
32
32
49
15
Create a policy.
Set the Outbound rule set to "All-inclusive with Audit rule set".
You see that:
The All-inclusive with Audit rule set has 2204 exploit attacks.
The total number of customized attacks for this policy is 2204 116 = 2038 customized attacks.
50
16
NS9300
NS9200
NS9100
NS7300
NS7200
NS7100
Aggregate
Performance
40 Gbps
20 Gbps
10 Gbps
5 Gbps
3 Gbps
1.5 Gbps
Max Throughput
with test
equipment
sending UDP
packet size of
1512 Bytes
up to 70
Gbps
up to 35
Gbps
up to 30
Gbps
up to 15
Gbps
up to 10
Gbps
up to 5
Gbps
Concurrent
Connections
32,000,000
16,000,000
13,000,000
10,000,000
5,000,000
3,000,000
Connections
established per
second
1,000,000
575,000
450,000
225,000
200,000
135,000
400,000
300,000
150,000
150,000
150,000
Supported UDP
Flows maximum
12,000,000
6,000,000
6,000,000
3,000,000
3,000,000
3,000,000
Supported UDP
Flows minimum
1,000
1,000
1,000
1,000
1,000
1,000
Latency
<100 s
<100 s
<100 s
<100 s
<100 s
<100 s
3,200,000
1,600,000
1,200,000
500,000
400,000
250,000
Number of SSL
certificates that
can be imported
into the Sensor
1,024
1,024
1,024
1,024
1,024
1,024
Throughput with
SSL Decryption
(based on 10%
SSL traffic)
40 Gbps
20 Gbps
10 Gbps
5 Gbps
3 Gbps
1.5 Gbps
Quarantine rules
per Sensor- IPv4
8,000
8,000
8,000
8,000
8,000
8,000
Quarantine rules
per Sensor- IPv6
500
500
500
500
500
500
51
16
Maximum Type
NS9300
NS9200
NS9100
NS7300
NS7200
NS7100
Quarantine Zones
per Sensor
50
50
50
50
50
50
Quarantine Zone
ACLs per Sensor
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
1,000
VLAN / CIDR
3,000
Blocks per Sensor
3,000
3,000
3,000
3,000
3,000
VLAN / CIDR
Blocks per
Interface
254
254
254
254
254
254
Customized
attacks
100,000
100,000
100,000
100,000
100,000
100,000
262,144
262,144
262,144
262,144
262,144
262,144
128,000
128,000
128,000
128,000
128,000
DoS Profiles
5,000
5,000
5,000
5,000
5,000
9,000,000
5,000,000
3,300,000
1,800,000
1,400,000
Effective
(Firewall) access
rules
20,000
20,000
10,000
5,000
3,000
3,000
Firewall rule
objects
140,000
140,000
70,000
35,000
21,000
21,000
5,000
5,000
2,500
1,250
1,000
1,000
Firewall rule
object groups
1,000
1,000
500
400
300
300
Application on
Custom Port rule
objects
2,000
2,000
1,000
500
500
500
Firewall
user-based rule
objects
5,000
5,000
2,500
1,250
1,000
1,000
Firewall user
groups in access
rules
10,000
10,000
10,000
10,000
10,000
10,000
Number of
whitelist entries
permitted for IP
Reputation
128
128
128
128
128
128
52
5,000
16
Maximum Type
NS9300
NS9200
NS9100
NS7300
NS7200
NS7100
Maximum host
entries supported
for Connection
Limiting policies
256,000
256,000
256,000
256,000
256,000
256,000
100 MB
100 MB
100 MB
100 MB
100 MB
100 MB
Passive device
profile limits
100,000
100,000
50,000
100,000
50,000
25,000
Advanced
50
Malware Maximum
simultaneous file
scan capacity with
file save
50
50
50
50
50
Advanced
Malware Maximum
simultaneous file
scan capacity
without file save
4,094
4,094
4,094
4,094
4,094
4,094
New HTTP
connections per
second(using 1
GET with 5000
HTTP response)
700,000
375,000
260,000
135,000
128,000
115,000
Create a policy.
Set the Outbound rule set to "All-inclusive with Audit rule set".
You see that:
The All-inclusive with Audit rule set has 2204 exploit attacks.
The total number of customized attacks for this policy is 2204 116 = 2038 customized attacks.
53
16
54
17
The following table describes the supported Virtual IPS Sensor capacity.
Table 17-1 Virtual IPS Sensor capacity by model number
Maximum Type
IPS-VM600
IPS-VM100
Aggregate Performance
600 Mbps
100 Mbps
Up to 1 Gbps
Up to 150 Mbps
Concurrent connections
600,000
200,000
20,000
6,000
25,000
10,000
254,208
39,168
Latency
NA
NA
NA
NA
NA
1,000
1,000
500
500
50
50
1,000
1,000
100
32
300
32
254
32
Customized attacks
100,000
20,000
Exception objects
131,072
32,768
100,000
20,000
DoS Profiles
300
100
600,000
200,000
2,000
1,000
55
17
IPS-VM600
IPS-VM100
14,000
7,000
750
500
200
100
250
150
750
500
2,000
2,000
64
32
55,000
15,000
10,000
32
16
1,024
255
Create a policy.
Set the Outbound rule set to "All-inclusive with Audit rule set".
You see that:
The All-inclusive with Audit rule set has 2204 exploit attacks.
The total number of customized attacks for this policy is 2204 116 = 2038 customized attacks.
56
18
M-1250/M-1450
TAP
SPAN
Dongles required
Inline fail-close
Port Speed/Duplex
10/100, Full/Half
Auto negotiation
Not supported
Warm reboot - inline fail-open Ports are enabled and in the down
(CLI reboot or reboot due to
state till the Sensor starts
error and watchdog on)
rebooting. Traffic is disrupted till
then.
Resetconfig
57
18
M-1250/M-1450
Not present
Not present
Not present
Not present
Link Events
Port density
Green - up
Green - up
Not present
Green - inline
Yellow - bypass
58
Red
Gray
Red
Red
Red
Red
Index
A
about this guide 5
active fail-open kits 17
asymmetric networks 27
C
conventions and icons used in this guide 5
D
documentation
audience for this guide 5
product-specific, finding 6
typographical conventions and icons 5
DoS attacks profiles; learning 20
exception objects 19
F
firewall policies 25
H
high-volume attacks; analyzing 19
HTTP response processing deployment 35
HTTP response traffic 35
processing results; I-series Sensors 37
processing results; M-series Sensors 37
processing results; Virtual IPS Sensors 37
S
Sensor capacity by model number
I-series 45
M-series 47
Virtual IPS 55
ServicePortal, finding product documentation 6
SSL best practices 29
T
technical support, finding product information 6
L
large Sensor deployments 15, 16
M
Manager server hardening;
installation 11
59
0E00