advertisement
T
RAFFIC
I
NSPECTION
In this section:
IPS and Layer 2 Firewall Policies - 113
103
104
C
H A P T E R
1 1
S
ITUATIONS
Situation elements collect together the information that identifies and describes detected events in the traffic (or in the operation of the system). Situations contain the context information, that is, a pattern that the system is to look for in the inspected traffic.
The following sections are included:
Overview of Situations (page 106)
Configuration of Situations (page 106)
Examples of Custom Situations (page 111)
105
Overview of Situations
Situations define the traffic patterns and events you want to detect in the Inspection Policy. The patterns and events are defined by selecting a Context for the Situation. The Context contains the information on the traffic to be matched, and the options you can set for the matching process.
Situations also provide a description that is shown in the logs, and a link to relevant external information (CVE/BID/MS/TA) in the form of a Vulnerability element attached to the Situation.
The Inspection Policy defines how the Situations are matched to traffic and what kind of action the engine takes when a match to a particular Situation is found. Correlation Situations are a special type of Situations that group together event data to find patterns in that data.
Configuration of Situations
The illustration below shows how Situations and the related elements are used together.
Illustration 11.1 A Situation and the Associated Elements
Tags
Context
Situation
Situation Type
Inspection
Policy
Vulnerability
The Situation element uses different elements to form a representation of the traffic that you want to detect in your Inspection Policy. The purpose of these elements is as follows:
• The Tag elements help you to create simpler policies with less effort. Tag elements represent all Situations that are associated with that Tag. For example, using the Tag “Windows” in a rule means that the rule matches all the Situations that concern Windows systems.
• The Situation Type elements define the general category of the Situation and the branch of the Rules tree under which the Situation appears (Attacks, Successful Attacks, etc.). One
Situation Type can be associated with each Situation.
• The Context element defines the traffic patterns the Situation detects. The Context binds the
Situation to a certain type of traffic and gives you a set of options or a field for entering a regular expression.
• The Vulnerability element associates your custom Situation with a commonly known vulnerability. It allows you to attach a description of the Vulnerability and references to public vulnerability databases (which are shown in the Logs view if a match is found).
The Context is the only mandatory element in a Situation. However, it is recommended to consistently associate all relevant Tags with each custom Situation you create. The vulnerability description is not mandatory, but it is helpful to have it for Situations that detect some publicly known issue.
106
Chapter 11 Situations
Situation Contexts
Context elements are protocol-specific, so they define what the Situation element matches.
They provide a framework for defining the parameters of each Situation. The parameters are entered as a regular expression or through a set of fields and options that you can adjust, depending on the Context element selected. The properties of each Context provide assistance on filling in the parameters for the Contexts.
The sections below explain the types of Context elements available and how they can be configured.
Note – The details related to the Contexts in your system may be different from what is described here because the Contexts may have been updated through dynamic update packages after this guide was published. Read the release notes of each update package you import to see which elements are affected.
Correlation Contexts
Correlation Contexts define the patterns for matching groups of related events in traffic. There are five types of Correlation Contexts:
Table 11.1 Correlation Context Types
Correlation
Context Type
Compress
Count
Group
Match
Description
Combines repeated similar events into the same log entry, reducing clutter in the
Logs view.
Example: There is a custom Situation for detecting suspicious access to a file server. An attacker is likely to browse through many files, triggering an alert entry for each file. An Event Compress Situation can be used to combine Situations together when the suspect’s IP address is the same.
Finds recurring patterns in traffic by counting how many times certain Situations occur within the defined period, so that action can be taken if the threshold values you set are exceeded.
Example: A Situation that detects access to a system could normally trigger just a log entry, but the Event Count Situation could be used to blacklist connections when access by any single host is too frequent.
Finds event patterns in traffic by keeping track of whether all events in the defined set of Situations match at least once in any order within the defined time period.
Example: Individual attempts to exploit different vulnerabilities in a software product in use on your server may not be too alarming if you know that your system is patched against those vulnerabilities. However, when several such events are found in a short period of time, it becomes more likely that someone is trying to systematically attack the server and already knows that the server is running that particular piece of software. A Situation that belongs to the Group Context can detect this.
Allows you to use Filters to filter event data produced by specific Situations.
Configuration of Situations
107
Table 11.1 Correlation Context Types (Continued)
Correlation
Context Type
Sequence
Description
Finds event patterns in traffic by keeping track of whether all events in the defined set of Situations match in a specific order within the defined time period.
Example: Clients may use a certain type of request (e.g., “give file X”) to fetch a file from a file server. When administrators log in to the same server, a successful administrator login can be seen in the traffic as a certain type of response (e.g.,
“full access granted”). However, a vulnerability in the server software may allow an attacker to send a specially crafted file fetch request that looks like a valid “give file x” command, but actually causes the server to give the attacker administrator access. This is seen as a normal-looking “full access granted” response from the server. The Event Sequence Situation can detect when a “give file X” Situation match is followed by a “full access granted” Situation match, which cannot be any legitimate traffic.
Detailed descriptions of the parameters for each of the Correlation Contexts can be found in
Situation Context Parameters (page 229).
DoS Detection Contexts
The DoS Detection Contexts provide parameters for detecting DoS (Denial of Service) events in network traffic.
Scan Detection Contexts
The Scan Detection Contexts provide parameters for detecting attempts to scan which IP addresses are in use or which ports are open in your systems.
Protocol-Specific Contexts
The protocol-specific Contexts are used to detect a particular characteristic in the network traffic. For example, you can detect a certain option number used in IP packets, or set the maximum length for particular arguments in FTP commands. You can also use the HTTP URL
Filter to allow or deny access to specific websites (not supported on Layer 2 Firewalls).
For Contexts that have particular values to be filled in (instead of a regular expression), the parameters you define in the Contexts often actually determine what is considered normal, so that anything above/below/outside/not matching these values is considered a match for the
Situation. In some cases, you may define what the Situation does not match.
Effective modifications to the protocol-specific Contexts require you to be familiar with the protocols in question and how the traffic in your network uses those protocols.
File Contexts
The File Contexts are used to detect malicious or suspicious content in transferred files regardless of the transport protocol used. When a file is detected, the file is inspected to identify the file type. Once the file type is identified, more specific inspection can be applied to the file.
108
Chapter 11 Situations
System Contexts
The System Contexts are used for errors and other system events. They are internal to the SMC, and they cannot be modified in any way.
Default Elements
There are many predefined Contexts, Situations, Tags, and Vulnerabilities available, which are imported and updated from dynamic update packages. This also means that the set of elements changes whenever you update your system with new definitions. Both Situation elements and Context elements have a comment and a longer description that you can view in the Management Client (in the Info panel or in the Properties dialog for the element) to see what each element is meant for.
The Release Notes of each dynamic update package list the new elements that the update introduces. If your Management Server can connect to the McAfee website, you can view the release notes directly through the Management Client.
Configuration Workflow
The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the McAfee SMC
Administrator’s Guide PDF.
Task 1: Create a Situation Element
You can create new Situations in addition to using the predefined ones. You can create a
Situation element to detect individual events or a Correlation Situation element to detect a group of related events. Situation elements can also be defined automatically based on Snort
rules when you import a Snort rules library. See Importing Snort Rules Libraries (page 160) for
more information.
A Situation element collects together the related elements and settings and sets the severity value for the Situation. The severity value can be set between Info (the least severe) to Critical
(the most severe). You can use the severity value to restrict which Situations added to the
Situations cell are considered in Inspection Exceptions and Alert Policies. For example, if a rule matches a large range of Situations you can create separate rules for less severe and more severe Situations.
Configuration of Situations
109
Task 2: Add a Context for the Situation
Adding a Context to a Situation allows you to define what kinds of patterns you want to look for in the traffic. For example, you can specify that you want to look for a certain character sequence in an HTTP stream from the client to the server.
Note – With the exception of whitelisted URLS in URL Filtering, Situations are identified only by the element name. Avoid matching the same pattern in different Situation elements. Situations with duplicate patterns can make the policy difficult to read and manage.
When you select a Context you get a set of options or a field for entering a regular expression as parameters for the Context. The parameters define the pattern you want to look for in the traffic.
The syntax for SMC regular expressions is explained in
Regular Expression Syntax (page 235).
Correlation Situation parameters are explained in Situation Context Parameters (page 229).
Other types of context parameters are not listed in this guide. They concentrate on some aspect of a particular kind of network traffic, and using them requires basic knowledge of the underlying network protocols. For more information on what a particular Context is used for, see the
Properties dialog of the Context in question.
Task 3: Associate Tags and/or Situation Types with the Situation
You can use Tag elements to group Situations and Situation Types to classify Situations. You can use predefined Tags or create new ones according to any criteria (for example, create a Tag for grouping together related services). Situation Types are predefined, and you cannot create new Situation Types. You can associate multiple Tags with one Situation, but only one Situation
Type can be associated with each Situation.
You can use the Tags and/or Situation Types to represent a group of Situations in the Rules and
Exceptions of the Inspection Policy. This allows you to match a rule to all Situations that contain the Tag or Situation Type. Situations that are associated with a Situation Type are automatically
included in the Rules tree. See Inspection Policies (page 151) for more information.
Note – If a Tag or Situation Type you add to a Situation is in use in some Inspection Policy, the new Situation is automatically included in the policy when you save the Situation, and the engines start matching traffic to the Situation when you refresh the policy.
Task 4: Associate the Situation with a Vulnerability
Vulnerabilities provide a short description of the event that has matched. Vulnerability information is included in dynamic update packages, so all Situations provided by McAfee that are related to a known vulnerability are linked to a Vulnerability element. When you create your own Situations, you can associate them with an existing Vulnerability or a custom Vulnerability element.
You can add up to four references to public vulnerability databases to your custom
Vulnerabilities (CVE/BID/MS/TA). System vulnerabilities can have an unlimited number of references to any reference system, and can have multiple references to the same reference system. The reference information is also shown in the Logs view.
110
Chapter 11 Situations
Using Situations
Situations are used for defining what you want to detect with the Inspection Policy. Situations are generally used for:
• Detecting malicious patterns in traffic. The Situations supplied by McAfee in dynamic update packages concentrate on such known vulnerabilities and exploits.
• Reducing the number of alert and log entries you receive (using Correlation Situations).
• Detecting some other traffic patterns that you want to record. For example, you may be interested in the use of certain applications.
Although the general workflow requires ensuring that a Situation you want to use is included in the Inspection Policy, you may often not actually insert the Situation into the rule, but use a Tag or Situation Type element instead to represent a whole group of Situations.
Examples of Custom Situations
The examples in this section illustrate some common uses for Situations and the general steps on how each scenario is configured.
Detecting the Use of Forbidden Software
Company A has an IPS engine deployed in between their internal network and the Internet. The
IPS engine uses a policy that is based on the IPS Template policy.
The administrators find out that some of the internal users have installed a piece of software on their computers that the company’s security policy forbids. They consider this software a security risk.
The administrators decide that they would like to detect the use of the software so that they can find out which users have installed it. The administrators find one simple but distinctive characteristic in the software: when launched, the software in question always connects to a particular address to check for updates using HTTP. The administrators:
1. Create a new custom Situation element with the name “Software X”.
2. Add the HTTP Client Stream Context to the Situation and type in a regular expression that contains the address they want the Situation to find using the SMC regular expression
syntax (see Regular Expression Syntax (page 235)).
3. Add one of the default Situation Types under Traffic Identification to the Situation.
4. Select the correct options for logging the traffic in the Rules tree in the Inspection Policy and install the policy on the IPS engine.
5. Open the Logs view and filter the view using the “Software X” Situation as the filtering criteria.
6. See which computers use the forbidden software and take action based on which IP addresses are shown in the logs.
Using Situations
111
Counting Events
Company B has a Firewall and an IPS engine that monitor traffic to a DMZ network. The DMZ contains a server that provides information to Company B’s partners. A while ago, users started complaining that the service had slowed down.
Upon investigation, Company B’s administrators found out that the traffic had grown dramatically even though the number of users and the data available had stayed the same. They found out that one of the partners had made a misconfigured script that frequently copied several large catalogs from Company B’s server to their own server and had given the script to a few other partners as well. As a first step, the administrators decide to immediately stop excessive queries to the server. The administrators:
1. Create a custom Situation for detecting access to the catalog files.
2. Create a custom Correlation Situation, attach the Count Context to it, and define the settings for the Count Context to detect when there are more than 5 requests per minute to any of the files from the same source address.
Table 11.2 Context Settings for the Example Correlation Situation
Field
Correlated Situations
Time Window
Alarm Threshold
Log Fields Enabled
Log Names
Option
Custom Situation
60
5
Select
Src Addr
3. Insert the Correlation Situation in the Inspection Policy with blacklisting as the Action. The traffic from the offending hosts will be stopped at the Firewall.
4. Refresh the Inspection Policy on the IPS engine.
Preventing Access to Forbidden Websites
The Administrators at Company C have noticed that employees frequently visit certain websites that are not related to their work. They want to block access to these websites to prevent employees from accessing them at work. To do this, they:
1. Create a new Situation element.
2. Add the Website Access Control Context to the Situation.
3. Specify the addresses they want to prevent access to. Access to the specified addresses will be blocked.
4. Refresh the Inspection Policy on the IPS engine.
112
Chapter 11 Situations
C
H A P T E R
1 2
IPS
AND
L
AYER
2 F
IREWALL
P
OLICIES
IPS and Layer 2 Firewall Policy elements are containers for the lists of rules that determine how the IPS and Layer 2 Firewall engines inspect traffic. The Policy elements include Template
Policies, Policies, and Sub-Policies.
The following sections are included:
Overview of IPS and Layer 2 Firewall Policies (page 114)
Configuration of Policy Elements (page 116)
Using Policy Elements and Rules (page 123)
Example of Policy Element Use (page 127)
113
Overview of IPS and Layer 2 Firewall Policies
IPS and Layer 2 Firewall Policy elements store rules according to which the IPS and Layer 2
Firewall engines examine the traffic. This chapter introduces you to how the IPS and Layer 2
Firewall engines use these elements. It also explains how you can build a purposeful and efficient policy hierarchy using the different policy elements. The basics of building the actual traffic handling rules that are contained in the policy elements are discussed in the chapters
that follow. See Ethernet Rules (page 129),
Policy Hierarchy
The policy structure in IPS and Layer 2 Firewalls is a hierarchical structure based on templates, which allows you to:
• Reuse rules without duplicating them.
• Assign and enforce editing rights of different parts of a single policy to different administrators.
• Reduce the resource consumption of the engines.
• Make policies easier to read.
IPS engines and Layer 2 Firewalls have separate Template Policies, Policies, and Sub-Policies.
The template and policy hierarchy is flattened when the Policy is transferred to the engines, so the policy will look the same to the engines regardless of how it is organized on the
Management Server (as long as the rules are in the same order). You can also create sections of conditional IPv4 Access rules that you can insert into the other policy elements. The engine may skip the processing of a conditional block of rules based on whether or not certain common matching criteria is found in the packet being examined.
If your environment is simple and you do not need the benefits outlined above, you have the option of creating a very simple policy hierarchy. You can start, for example, with a single custom IPS Policy or Layer 2 Firewall Policy built on one of the pre-defined IPS Template Policies or Layer 2 Firewall Template Policies. You can use the same IPS Policy on any number of IPS engines and Virtual IPS engines, and the same Layer 2 Firewall Policy on any number of Layer 2
Firewalls and Virtual Layer 2 Firewalls.
How IPS Engines and Layer 2 Firewalls Examine Traffic
An IPS or Layer 2 Firewall engine matches traffic to different protocols and then checks the definitions for known vulnerabilities and other threats for that protocol. The protocol is assigned first, before the deep inspection. An engine in inline mode can also filter traffic based on protocols, IP addresses, and the interface that received the traffic without analyzing the traffic for threat patterns. IPS engines and Layer 2 Firewalls can be installed either in inline mode or in
capture mode. See NGFW Deployment in IPS and Layer 2 Firewall Roles (page 29) for more
information.
114
Chapter 12 IPS and Layer 2 Firewall Policies
shows how an engine in inline mode inspects traffic.
Illustration 12.1 Packet/Connection Handling in an inline IPS or Layer 2 Firewall Engine
1.
2.
3.
4.
1. The engine checks Ethernet frames against the Ethernet rules in the policy. The packet is processed until it matches an Ethernet rule that tells whether to allow or to discard the packet.
2. The engine checks the current connection tracking information to see if the packet is part of an established connection (for example, a reply packet to a request that has been allowed).
3. If the packet is not part of an existing connection, the packet is matched to IPv4 or IPv6
Access rules according to the IP protocol used.
• If the traffic is tunneled using IP-in-IP or Generic Routing Encapsulation (GRE), the traffic can be checked against the IPv4 and/or IPv6 Access rules several times according to the number and type of layers in the tunnel and the settings of the engine.
• The processing of the packet continues until the packet matches a rule that tells the engine to allow or discard the packet. If the packet does not match any Access rule, the
Overview of IPS and Layer 2 Firewall Policies
115
final action depends on the engine type. An IPS engine allows the packet to pass through, while a Layer 2 Firewall drops the packet.
4. The engine matches connections that are selected for deep packet inspection in the IPv4 or IPv6 Access rules against the Inspection rules.
• The Inspection rules are used to look for patterns of interest in allowed connections. The patterns may indicate potential attacks, exploits, or other possible threats. Alternatively, they can be any other patterns that might be of interest, such as multiple login attempts, use of peer-to-peer or instant messaging software, or protocol violations in the traffic.
• If a pattern in traffic matches a pattern defined in a rule, the action(s) defined in the rule are taken.
Configuration of Policy Elements
IPS engines and Virtual IPS engines use IPS Policies, and Layer 2 Firewalls and Virtual Layer 2
Firewalls use Layer 2 Firewall Policies. Master Engines always use Firewall Policies regardless of the role of the Virtual Security Engines they host.
There are four kinds of IPS and Layer 2 Firewall Policy elements:
• A Template Policy is a policy that can be used as the basis for Policy or other Template Policy elements. The rules in the Template Policy are copied as inherited rules into the Policies and
Template Policies that are based on the Template Policy. You can modify the inherited rules only by editing the original Template Policy from which the rules were inherited.
• An Inspection Policy element is a set of Inspection rules that are referenced from the
Inspection tab of Policy and Template Policy elements. You can use the same Inspection
Policy in multiple Policy and Template Policy elements.
• A Sub-Policy element is a section of IPv4 Access rules that you can insert into Policies and
Template Policies. The rules in the Sub-Policy are conditional rules that allow you to define matching criteria that determines whether the Sub-Policy applies to a connection. You can modify the rules by editing the Sub-Policy where the rules belong.
• A Policy element is an element that gathers together all the rules from the different policy elements (the rules added directly to the IPS Policy or Layer 2 Firewall Policy, the rules from the higher-level Template Policy, and possibly rules from one or more Sub-Policies). An IPS
Policy is always based on an IPS Template Policy element. A Layer 2 Firewall Policy is always based on a Layer 2 Firewall Template Policy element. IPS Policies and Layer 2 Firewall Policies are the only type of policy elements that can be installed on engines.
The hierarchy of how rules are inherited between different policy elements is shown in
.
116
Chapter 12 IPS and Layer 2 Firewall Policies
Illustration 12.2 Rule Inheritance
Template
Policy A
Template
Policy B
Sub-Policy
Policy
Rules:
Template Policy A
+ Template Policy B
+ Sub-Policy + Policy
, Template Policy A is the basis for Template Policy B, so Template Policy B contains all the rules defined in Template Policy A. Template Policy B also contains all the rules in an Sub-Policy, as well as rules defined directly in Template Policy B. The example Policy inherits the following rules:
• All the rules in Template Policy A.
• All the rules in Template Policy B.
• All the rules in the Sub-Policy.
Inherited rules cannot be edited in the policy that inherits the rules. For example, to change rules inherited from Template Policy A, administrators must have privileges to edit the Template
Policy A in which the rules were originally defined.
A hierarchy such as the one outlined above is useful to:
• Reduce the need for creating the same or similar rule in several policies. For example, any rule added to Template Policy A is also added to any policy created based on Template Policy
A. The next time Policies based on Template Policy A are installed on engines, the new rule is used on all the engines without the need to directly modify each individual Policy.
• Restrict the editing rights of administrators. For example, administrators who are granted rights only to Policy elements cannot edit the rules inherited from the Policy Templates. Their actions have no effect on rules that are placed above the row where the Template Policy allows them to insert new rules. In the hierarchy shown in the illustration above, the insert point(s) for the Policy are defined in Template Policy B, which in turn can be edited only in the place where there is an insert point in Template Policy A.
• Reduce the likelihood of mistakes affecting important communications. Template Policies can be reserved for defining only the rules for essential communications, so that most daily editing is done in the lower-level Policies. If the Template Policy is properly designed, the rules in the Template Policy cannot be overridden by any rules in the lower-level policy. Good organization also makes policies easier to read, further reducing the risk of errors.
• Improve processing performance. With the help of Sub-Policies, whole blocks of rules may be skipped during processing when a connection does not match the rule that directs the traffic processing to the Sub-Policy. This reduces the processor load, which may lead to improved throughput if the processor load is constantly very high.
Configuration of Policy Elements
117
Default Elements
The default policy elements are introduced when you import and activate a recent dynamic update package (for example, during the installation). The elements may change when you install newer update packages.
None of the default policy elements can be modified. However, you can make copies of the default policies if you need to create a modified version.
The following table describes the default policy elements for IPS and Layer 2 Firewall engines.
Table 12.1 Default Policy Elements for IPS and Layer 2 Firewall Engines
Element
Type
Default
Element
Name
Description
IPS
Template
Policy
IPS Template
A Template Policy that contains the predefined Access rules necessary for the IPS engine to communicate with the SMC and some external components. The predefined Access rules are explained in
The IPS Template Policy uses Inspection rules from the High-Security
Inspection Policy. The IPS Template Policy provides an easy starting point for determining what kinds of rules your system needs.
Customized
High-Security
Inspection
IPS Policy
An IPS Policy that is based on the IPS Template. The Customized High-
Security Inspection IPS Policy contains a set of customized rules that were used when the IPS was tested at ICSA Labs and NSS Labs.
IPS Policy
Layer 2
Firewall
Template
Policy
Default IPS
Policy
Layer 2
Firewall
Template
Layer 2
Firewall
Inspection
Template
An IPS Policy that is based on the IPS Template. The Default IPS Policy does not add any rules to those defined in the IPS Template. It allows you to install the predefined rules in the IPS Template on the IPS engine right after installation (since Template Policies cannot be installed on the engines).
A Template Policy that contains the predefined Access rules necessary for the Layer 2 Firewall to communicate with the SMC and some external components. The predefined Access rules are explained in
The Layer 2 Firewall Template uses Inspection rules from the No
Inspection Policy. The rules in the No Inspection Policy do not enforce inspection.
A Template Policy that is based on the Layer 2 Firewall Template. It uses
Inspection rules from the High-Security Inspection Policy.
The Layer 2 Firewall Inspection Template enables deep inspection for all traffic.
118
Chapter 12 IPS and Layer 2 Firewall Policies
Table 12.1 Default Policy Elements for IPS and Layer 2 Firewall Engines (Continued)
Element
Type
Default
Element
Name
No
Inspection
Policy
Description
An Inspection Policy with a set of Inspection rules that do not enforce inspection.
Inspection
Policy
Medium-
Security
Inspection
Policy
Inspection
Policy
(cont.)
High-Security
Inspection
Policy
Customized
High-Security
Inspection
Policy
An Inspection Policy with a set of Inspection rules for detecting common threats. The Medium-Security Inspection Policy logs Situations categorized as Suspected Attacks but allows the traffic to pass.
The Medium-Security Inspection Policy is suitable for Firewall, Layer 2
Firewall, Master Engine, and Virtual Security Engine deployments. It is also suitable for inline IPS deployments in asymmetrically-routed networks and IPS deployments in capture mode. The risk of false positives is low in production use.
An Inspection Policy with a set of Inspection rules for detecting common threats. The High-Security Inspection Policy terminates Suspected Attacks with an alert.
The High-Security Inspection Policy is suitable for Firewall, Layer 2
Firewall, inline IPS, Master Engine, and Virtual Security Engine deployments where extended inspection coverage and strong evasion protection is required. The risk of false positives is moderate in production use.
The High-Security Inspection Policy terminates a connection if the engine cannot see the whole connection. We recommended that you use the
High-Security Inspection Policy as a starting point for your Inspection
Policies.
An Inspection Policy that is based on the High-Security Inspection Policy and contains a set of customized Inspection rules.
The High-Security Inspection Policy is an example of a highly customized
Inspection Policy for network environments in which unconditional inspection coverage and evasion protection are required. The risk of false positives is high in production use.
The High-Security Inspection Policy was used when the IPS was tested at
ICSA Labs and NSS Labs. It provides an example of a customized
Inspection Policy.
You can add new Template Policies without basing them on any existing Template Policy.
However, in most cases we recommend using the IPS Template as the starting point for your customized IPS Template Policies and IPS Policies, and the Layer 2 Firewall Template as the starting point for your customized Layer 2 Firewall Template Policies and Layer 2 Firewall
Policies.
Situations are the central elements in the Inspection rules of your Inspection Policies. The
Situation elements detect exploit attempts against known vulnerabilities and other commonly known security threats. Because dynamic updates include new and updated Situations, new patterns in traffic may begin to match when a new dynamic update is activated and you refresh the Inspection Policy.
Configuration of Policy Elements
119
In most environments we recommend using the High-Security Inspection Policy as the starting point for Inspection Policies. The High-Security Inspection Policy provides extended inspection coverage. It also protects the network against evasions, which are attempts to disguise attacks in order to avoid detection and blocking by network security systems. The only difference between the rules in the High-Security Inspection Policy and the Medium-Security Inspection
Policy is in the way the Inspection rules handle Situations that are categorized as Suspected
Attacks. The High-Security Inspection Policy terminates Suspected Attacks with an alert, whereas the Medium-Security Inspection Policy only logs Suspected Attacks.
Situations that belong to the Suspected Attacks category contain basic fingerprints. Suspected
Attacks also contain traffic patterns that may indicate malicious activities but are not any verified attack patterns. Suspected Attacks can catch zero-day attacks (attacks that are not yet publicly known), but may sometimes block some legitimate traffic if the traffic pattern happens to resemble malicious activities.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Policy elements are merely containers for the actual traffic handling rules. When you have decided on a policy hierarchy, you can populate the policy elements with the actual rules for handling the traffic. See
Task 1: Create a Template Policy
IPS Template Policy elements are used as a basis for other IPS Policies and IPS Template
Policies. Layer 2 Firewall Template Policy elements are used as a basis for Layer 2 Firewall
Policies and other Layer 2 Firewall Template Policies.
Every IPS Policy and Layer 2 Firewall Policy that you create is based on a Template Policy. You can also base several policies on the same Template Policy. Although it is possible to create custom Template Policies without basing them on any of the pre-defined templates, we recommend basing your IPS Policies on the IPS Template and your Layer 2 Firewall Policies on the Layer 2 Firewall Template. Updated versions of the Templates are included in dynamic update packages, so the policies that inherit rules from the pre-defined Templates are automatically updated when you activate a new dynamic update. Policies based on a copy of the pre-defined templates or a completely different Template are not automatically updated.
When editing the policies, the main difference between Template Policies and Policies are the special rows called Insert Points. Insert points are shown in both Template Policies and Policies, but you can add them only to Template Policies. The insert points added to templates mark the places where new rules can be added to Policies that are based on the templates. If you create a new Template Policy and do not base the Template Policy on any pre-defined Template Policy, you must add insert points on the Ethernet and Access tabs to be able to add rules on each tab.
120
Chapter 12 IPS and Layer 2 Firewall Policies
Illustration 12.3 Insert Point in a Template and the Inheriting (Template) Policy
shows an example of what the same insert point looks like in an IPS Template
Policy and in the inheriting IPS Policy elements. The color of the insert point indicates whether the insert point has been added in the IPS Template Policy for inheritance to lower levels
(orange) or whether it has been inherited from the higher-level template (green). Only the orange insert points are inherited to lower-level policy elements, so you must add at least one new insert point to each template you create to make the lower-level policies editable. When you add the first new rule to the green insert point, the rule replaces the insert point. Any number of rules can then be added directly above and below that first rule.
Rules defined in the Template Policy itself are not editable in lower-level policies that use the template. Such inherited rules are shown only on your request and they have a gray background.
Only the actual rules are inherited from a higher-level template into the lower-level policies and templates. The rights to edit policies and Template Policies are defined separately.
Because the IPS and Layer 2 Firewall engines read rules in order from top down, rules above the insert point in the higher-level template cannot be cancelled by anything a lower-level policy adds below the insert point.
Task 2: Create a Policy
An IPS Policy or a Layer 2 Firewall Policy is the element that gathers together all the rules from the different policy elements: the rules inherited from the Template Policy that is used as the basis of the policy, rules from one or more Sub-Policies added to the policy, rules added directly to the policy, and the rules from the Inspection Policy that is referenced from the Inspection tab in the policy.
Task 3: Create a Sub-Policy
Sub-Policies are sections of IPv4 Access rules that you can insert into IPS Policies, IPS Template
Policies, Layer 2 Firewall Policies, Layer 2 Firewall Template Policies, and even other IPS Sub-
Policies or Layer 2 Firewall policies. The Sub-Policies are not based on any template. Apart from
IPv4 rules, you cannot insert any other types of rules into IPS Sub-Policies or Layer 2 Firewall
Policies.
Using Sub-Policies can make the engines process traffic faster. You can also use Sub-Policies to organize rules. Sub-Policies may make reading the policies and assigning administrator editing rights easier. For example, you can give some administrators the rights to edit only certain IPS
Sub-Policies or Layer 2 Firewall Sub-Policies without giving editing rights to IPS Policies or Layer
2 Firewall Policies.
A Sub-Policy is inserted into some other policy element by adding a Jump rule to the policy element. The Jump rule directs connections that match the criteria defined in the Jump rule for inspection against the Sub-Policy.
Configuration of Policy Elements
121
Illustration 12.4 An Example of an IPS Sub-Policy in Use
A Jump rule inserts the
Sub-Policy, which is shown as an expandable section.
The illustration above shows the same Jump rule in a policy in the collapsed and the expanded state. The rules of the Sub-Policy are shown on a gray background, because they can be edited only within the Sub-Policy itself, not in the Policy that uses the rules.
For example, you could create a Sub-Policy for checking traffic destined to a group of servers located in one particular network. The Jump rule could then use the destination network as a criteria for directing connections for checking against the Sub-Policy. Any connection that was destined to some other network would not get matched against any of the rules in the Sub-
Policy. This makes the Access rule processing faster, because the engine can skip a whole Sub-
Policy by comparing a connection to just one simple rule for any non-matching connection. If the
Sub-Policy rules were inserted directly into the main Policy, the engine would have to compare all connections to all those rules individually. Naturally, the performance benefit gained depends on the number and complexity of the rules that can be placed in a Sub-Policy and how heavily stressed the engine is to begin with. Therefore, Sub-Policies are mainly useful in the policies of inline IPS or Layer 2 Firewall engines that are used extensively for IPv4 packet filtering.
Task 4: Install the Policy
After creating or modifying an IPS Policy or Layer 2 Firewall Policy, you must transfer the changes to the engines using the Management Client.
The policy transfer includes more information than just the rules in the IPS Policy or Layer 2
Firewall Policy. Whenever you update the engine’s configuration, you must refresh the IPS Policy or the Layer 2 Firewall Policy to make the changes take effect. After you have modified Physical
Interfaces or VLAN Interfaces in the Master Engine properties, you must refresh the policy on the Master Engine to transfer changes. After you have modified Physical Interfaces or VLAN
Interfaces in the Virtual IPS or Virtual Layer 2 Firewall engine properties, you must refresh the policy on the Virtual IPS or Virtual Layer 2 Firewall engine to transfer the changes.
If the installation of a policy fails for some reason, the system automatically rolls back to the previously installed configuration.
122
Chapter 12 IPS and Layer 2 Firewall Policies
Using Policy Elements and Rules
The main points of using policy elements are explained in the preceding sections of this chapter.
The sections below illustrate additional points that are useful to know when working with policies and rules:
•
•
•
Connection Tracking vs. Connectionless Packet Inspection (page 124)
•
•
•
Adding Comments to Rules (page 126)
•
Validating the Policy
The number of rules in a policy may grow quite large over time. It may become quite difficult, for example, to notice configuration errors in a policy. To make policy management easier and make sure that the policy does not contain misconfigured rules, you can automatically validate the policy while editing and during the policy installation. There are different criteria for validating the policy. You can, for example, check the policy for duplicate and empty rules or check if there are rules that cannot ever match traffic.
User Responses
The User Response element allows you to send a configurable reply to the client instead of just ending the TCP connection when an HTTP connection is terminated or blacklisted. The reply can be a custom error message, or an HTTP redirect to a specified URL. The User Response is selected in the Action options in Access rules and in the Exceptions in the Inspection Policy.
Using Policy Elements and Rules
123
Connection Tracking vs. Connectionless Packet Inspection
Connection tracking means that the engine keeps a record of all currently open connections
(stateful inspection). With connection tracking, the engine can verify that the connection proceeds according to the protocol standards. Connection tracking is also required for enforcing some other connection-related settings. By default, connection tracking is on.
However, it is not necessary to keep track of the state of certain kinds of connections (for example, SNMP traps). Some applications may also communicate in a non-standard way that prevents them from being allowed through the engine when connection tracking is used. For those connections, you can disable connection tracking in the Access rules. This allows the engine to function as a simple packet filter for those connections. This also prevents the use of some features that require connection tracking.
When connection tracking is off, each packet that you want to allow must match an Access rule that allows the packet. This means that even if two-way communications are always opened one way, both directions of communication must be explicitly allowed in Access rules. Reply packets are not recognized, so they are not automatically allowed through. If done carelessly, turning connection tracking off reduces the benefits you gain from your engine and may even weaken security. You may have other options: in some cases using the correct Protocol Agent helps.
Note – Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question. The Protocol Agents can pass connections that require special handling when connection tracking is on, which is always a more secure option.
When connection tracking is enabled in an Access rule, the Service cell of the rule must contain one of the protocols supported for connection tracking (ICMP, TCP, UDP, or another protocol that belongs to the IP protocol suite). ICMP and UDP are stateless protocols that do not contain any connection data. However, ICMP and UDP packets contain data that the engine can use to build virtual connections. The engine can also build virtual connections based on the IP address and
IP protocol data in other types of IP packets.
You can choose between several connection tracking modes, depending on the traffic type and how strictly you want the connections to be tracked. The effect of the connection tracking mode
set in the Access rules depends on the traffic type. The available options are explained in Table
Table 12.2 Connection Tracking Modes in Access Rules
Option
Inherited from
Continue
Rule(s)
Explanation
The connection tracking setting defined in Continue rule(s) higher up in the policy is used.
The additional options available for connection tracking are explained in the next table.
Note!
If connection tracking is disabled in Continue rule(s) higher up in the policy, the IPS or
Layer 2 Firewall engine behaves as described in the Off (Not recommended) explanation below.
124
Chapter 12 IPS and Layer 2 Firewall Policies
Table 12.2 Connection Tracking Modes in Access Rules (Continued)
Option
Off (Not recommended)
Defined in
Engine
Properties
Normal
Strict
Loose
Explanation
Connection tracking is disabled. The IPS or Layer 2 Firewall engine operates as a simple packet filter and allows packets based on their source, destination, and port. You must add separate
Access rules that explicitly allow the reply packets. NAT cannot be applied to traffic allowed without connection tracking.
Note!
Turn off logging in the rule if you disable connection tracking. When connection tracking is off, a log entry is generated for each packet. This may put considerable strain on the engine, network, and the Log Server.
The IPS or Layer 2 Firewall engine allows or discards packets according to the Connection
Tracking mode selected in the engine properties.
Protocols that use a dynamic port assignment must be allowed using a Service with the appropriate Protocol Agent for that protocol (in Access rules and NAT rules).
The Normal mode is the default Connection Tracking mode for Layer 2 Firewalls.
The IPS or Layer 2 Firewall engine drops ICMP error messages related to connections that are not currently active in connection tracking (unless explicitly allowed by a rule in the policy). A valid, complete TCP handshake is required for TCP traffic. The IPS or Layer 2 Firewall engine checks the traffic direction and the port parameters of UDP traffic. If the Service cell in the rule contains a Service that uses a Protocol Agent, the IPS or Layer 2 Firewall engine also validates
TCP and UDP traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
The IPS or Layer 2 Firewall engine allows only TCP traffic that strictly adheres to the TCP standard as defined in RFC 793. The IPS or Layer 2 Firewall engine also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops packets that are out of sequence. If the Service cell in the rule contains a Service that uses a Protocol Agent, the IPS or Layer 2 Firewall engine also validates the traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
The Loose mode is the default Connection Tracking mode for IPS engines.
Allows some connection patterns that are not allowed in the Normal mode. Can be used, for example, if routing is asymmetric and cannot be corrected or if the use of dynamic routing protocols causes the IPS or Layer 2 Firewall engine to receive non-standard traffic patterns.
This is the recommended connection tracking mode for Layer 2 Firewalls, IPS engines, Virtual
Layer 2 Firewalls, and Virtual IPS engines when they are configured by default to only log connections instead of terminating them. See the McAfee SMC Administrator’s Guide for more information on the Default Connection Termination settings for each engine type.
If Connection Tracking is on, you can also set the Idle Timeout for connections. The timeout is meant for clearing the engine’s records of old connections that the communicating hosts leave hanging. The timeout concerns only idle connections, so connections are not cut because of timeouts while the hosts are still communicating. The timeout defined for an Access rule overrides the default idle timeout value that is set for the protocol in the engine’s properties.
Caution – Setting excessively long timeouts for a large number of connections may consume engine resources and degrade engine performance and stability. Be especially careful when defining timeouts for ICMP and UDP. The ICMP and UDP virtual connections do not have closing packets, so the engine keeps the records for the ICMP and UDP connections until the end of the timeout.
Using Policy Elements and Rules
125
Connection tracking options in Access rules also allow you to override the limit for concurrent connections from a single source and/or destination IP address defined on the Advanced tab in the Security Engine properties, in Virtual Resource properties, and in the properties of some interface types. When the set number of connections is reached, the next connection attempts are blocked by the engine until a previously open connection is closed.
Changes in the connection tracking mode affect how existing connections are handled when you install or refresh the policy. When you install or refresh the policy on an engine, the engine checks if the existing connections are still allowed in the policy. If the connection tracking mode changes from Loose to Strict, existing virtual ICMP connections are only allowed if they began with a valid packet (for example, not with a response packet). In addition, if the mode changes from Normal to Strict, existing TCP connections are only allowed if all the packets in the connection have been seen. In all other cases, changes in connection tracking mode do not affect existing ICMP, TCP, and UDP connections at policy installation.
Policy Snapshots
A Policy Snapshot is a stored record of a policy configuration. A Policy Snapshot is stored in an engine’s upload history whenever a policy is installed or refreshed on the engine. The Policy
Snapshots allow you to check which IPS Policies and other configuration information were uploaded, and when they were uploaded. You can also compare any two Policy Snapshots and see the differences between them.
Continue Rules
The Continue action for a rule sets default options (such as logging options) for the traffic matching process. Options set in Continue rules are used for subsequent rules that match the same criteria as the Continue rule, unless the rules are specifically set to override the options.
Continue rules are also very useful in the hierarchical structure of the policies. IPS Template
Policies and Layer 2 Firewall Template Policies are particularly convenient for setting options with a Continue rule, because all the Policies and Template Policies that use the template inherit the option settings you have specified. Continue rules are explained in detail in
Configuring Default Settings for Several Rules (page 146).
Adding Comments to Rules
Each policy can include a large number of rules. Adding comments provides administrators with useful information and also makes it easier to read policies. You can add comments to all types of rules. In rule tables, you can add comments in the rule’s Comment cell. You can also a Rule
Section, which begins with a comment row and can include one or more rules.
The Rule Section automatically includes all the rules below the Rule Section until the next Rule
Section in the policy. You can expand and collapse the Rule Sections as necessary. The comment row in a Rule Section is displayed against a colored background (with configurable colors). This makes Rule Sections particularly useful in visually separating the sections of rules within a single policy.
126
Chapter 12 IPS and Layer 2 Firewall Policies
Naming Rules
In addition to comments, it is possible to specify an optional name or short description for
Access rules and Ethernet rules in IPS and Layer 2 Firewall Policies, Exceptions in Inspection
Policies, and rules in QoS Policies and Alert Policies. Names help administrators identify individual rules in large rule tables. You can also search for a rule by its name. If a rule has been named, the name is displayed in the Logs view as well.
Example of Policy Element Use
This section illustrates a common use for the different policy elements and general steps on how the scenario is configured.
Restricting Administrator Editing Rights
Company A is implementing a distributed network with multiple sites, one central office where most of the administrators work, and a number of branch offices in different countries. The branch offices mostly have IT staff with only limited networking experience, but who are still responsible for the day-to-day maintenance of the network infrastructure and the IPS engines at their site. They must be able to, for example, add and remove Access rules for testing purposes without always contacting the main administrators.
The administrators decide to limit the privileges of the branch office IT staff so that they are not able to edit the policies of the IPS engines at any of the other sites. The administrators:
1. Create a new IPS Template Policy based on the pre-defined IPS Template.
2. Add rules to the IPS Template Policy using Alias elements to cover the essential services that each of these sites have.
• Using a common IPS Template Policy for all the branch offices eliminates the need to make the same changes in several policies, easing the workload.
3. Create a new IPS Policy based on the new template for each of the branch office sites.
• Although a single IPS Policy for all sites could work, in this case the administrators decide against it, as separate policies are needed for the separation of editing rights. The policies are based on the same template, so rules can still be shared without duplicating them manually.
4. Grant each IPS Policy to the correct IPS engine elements.
• After this, only the correct IPS Policy can be installed on each IPS engine. No other policy is accepted.
5. Create new accounts with restricted rights for the branch office administrators and grant the correct IPS engine element and IPS Policy to each administrator.
• The branch office administrators are now restricted to editing one IPS Policy and can install it on the correct IPS engine.
• The branch office administrators are not allowed to edit the template the IPS Policy is based on, nor can they install any other policies on any other IPS engines.
Administrator rights are explained in more detail in the McAfee SMC Reference Guide.
Example of Policy Element Use
127
128
Chapter 12 IPS and Layer 2 Firewall Policies
C
H A P T E R
1 3
E
THERNET
R
ULES
Ethernet rules are lists of matching criteria and actions that define whether Ethernet protocol traffic is allowed or discarded.
The following sections are included:
Overview of Ethernet Rules (page 130)
Configuration of Ethernet Rules (page 130)
Using Ethernet Rules (page 135)
Examples of Ethernet Rules (page 135)
129
Overview of Ethernet Rules
Ethernet rules are used by inline IPS engines or Layer 2 Firewalls in Transparent Access Control mode, by inline Virtual IPS engines, and by Virtual Layer 2 Firewalls. Ethernet rules define which
Ethernet protocol packets the engines stop, and which packets are allowed through. Ethernet rules can also be used by IPS engines, Layer 2 Firewalls, Virtual IPS engines, and Virtual Layer
2 Firewalls in capture mode to define how Ethernet protocol traffic is logged. The Ethernet rules are stored in policy elements, which are discussed in
IPS and Layer 2 Firewall Policies
The traffic matching in Ethernet rules is based on the Source and Destination MAC Address in the packets. Any Ethernet network traffic, such as ARP, RARP, IPv6, Cisco Discovery Protocol
(CDP), and Spanning Tree Protocol (STP), can be checked against the Ethernet rules. Ethernet traffic can be allowed or discarded. For IPS engines or Layer 2 Firewalls in capture mode, only the Allow action is available.
Regardless of the action taken, a matching rule can also create a log or alert entry.
Configuration of Ethernet Rules
Ethernet rules are configured on the Ethernet tab inside IPS and Layer 2 Firewall Policy and
Template Policy elements. IPS and Layer 2 Firewall Sub-Policies cannot contain Ethernet rules.
Illustration 13.1 Newly Inserted Ethernet Rule - Main Cells
Engine applies Action when it finds a match
displays an Ethernet rule that has just been inserted into the policy. The
Source, Destination, and Service cells are set to NONE, so this rule never matches until they are changed to ANY or some more specific value. The Logical Inteface cell is also matched against traffic, but it is not mandatory to change it if you want the rule to apply regardless of the interface. The other editable cells specify further conditions and options for handling matching connections. It is not necessary to modify all cells in each rule.
Before starting to build policies, make sure you understand the network element types available and how you can use them efficiently to define the resources that you want to protect and control. The illustration below shows the types of elements that you can use in Ethernet rules.
130
Chapter 13 Ethernet Rules
Illustration 13.2 Elements in Ethernet Rules
Logical
Interfaces
MAC
Addresses
Services
The table below explains briefly what each Ethernet rule cell does and which elements you can use in the rules. More information on each cell is included in the task flow later in this chapter.
Table 13.1 Ethernet Rule Cells
Cell
ID
Logical
Interface
Source
Destination
Service
Action
Logging
Comment
Rule Name
Explanation
(Not editable) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers.
Matches the rule based on which interface the traffic is picked up from. The same logical interface may be assigned to one or several interfaces as configured in the properties of the IPS engine or Layer 2 Firewall. This cell accepts only Logical Interface elements.
Elements containing the MAC addresses that the rule matches. Both the Source and the Destination defined must match the source and destination of a packet for the packet to match the rule. The Source and Destination cells accept MAC Address elements.
The Services match an Ethernet frame type. The Service cell accepts Ethernet Services elements.
Command for the engine to carry out when a connection matches the rule.
The options for logging.
An optional free-form comment for this rule. You can also add separate comment rows in between rules.
Contains a rule tag and optionally a rule name.
Name: (Optional) Name or description for the rule. Displayed alongside the rule tag.
Tag: (Not editable) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @20.1). The first part of the tag is permanent and belongs to only that rule. The second part changes when the rule is changed. The first part and the second part are separated by a period.
Configuration of Ethernet Rules
131
Considerations for Designing Ethernet Rules
Ethernet rules are read from the top down. More specific rules must be placed above more general rules that match the same traffic. The actions Allow and Discard stop the processing from continuing down the rule table for any packet that matches the rule. Rules with these actions must be placed so that the more limited the rule is in scope, the higher up in the rule table it is. If the traffic does not match any of the Ethernet rules by the end of the policy, it is allowed by default.
Default Elements
The IPS Template and the Layer 2 Firewall Template contain predefined Ethernet rules. Because the template policies are added and updated through dynamic update packages, the templates you currently have in your SMC may look slightly different from the one that is presented in this section. Newer versions of the templates work in the same way as described below. Any changes to the templates are documented in the Release Notes document for each dynamic update package. The predefined Ethernet rules allow the most common types of Ethernet traffic.
Illustration 13.3 IPS Template - Ethernet Rules
In the illustration above, you can see a green insert point at the top of the rule table, three default rules below it, and then another insert point below them.
• The first rule contains common Ethernet protocols and allows the matching traffic to pass through.
• The second rule contains the IPv4 protocol and allows IPv4 traffic with further inspection against the IPv4 Access rules.
• The third rule contains the IPv6 protocol and allows IPv6 traffic with further inspection against the IPv6 Access rules.
The two insert points indicate where you can add Ethernet rules to a policy that uses the IPS
Template or the Layer 2 Firewall Template. The first insert point above the default rules allows you to modify and make exceptions to how traffic that matches the three default rules is checked. For example, you could add a rule defining that no IPv4 or IPv6 traffic at all is allowed between certain MAC addresses.
The second insert point below the default rules allows you to define how traffic that matches other protocols is checked. The final rule allows all traffic.
132
Chapter 13 Ethernet Rules
Configuration Workflow
The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Define the Source and Destination
The source and destination MAC addresses specified in a rule are compared to the MAC addresses in each packet’s header. Based on these and other criteria, the rule is applied to matching packets. By default, these cells are set to NONE, and you must change the value in both cells to make the rule valid.
The Source and Destination cells accept MAC address elements. You can set these cells to ANY to make the rule match all possible source or destination MAC addresses. You can also add more than one element in each cell to make the rule match multiple MAC addresses.
Task 2: Define the Service
The Service cell defines which protocol(s) the rule you design applies to. By default, the Service is set to NONE, and you must change the value to make the rule valid. The Service cell accepts only Ethernet Services elements. You can set the Service to ANY to make the rule match all protocols.
Task 3: Select the Action
The Action cell defines what happens when a packet matches the rule. The following actions are available in the Ethernet rules:
• Allow: the traffic is let through the engine.
• Discard: the traffic is silently dropped if going through an Inline interface.
Note – When the Allow action is used for IPv4 or IPv6 traffic in the Ethernet rules, the traffic is then checked against the IPv4 Access rules or the IPv6 Access rules. The final action for the IPv4 and IPv6 traffic is determined according to traffic type by the IPv4
Access rules or the IPv6 Access rules.
Configuration of Ethernet Rules
133
Task 4: Select Logging Options
Rules can create a log or alert entry each time they match. By default, logging options set in a previous rule with Continue as its action are used. If no such rule exists, Layer 2 Firewalls and
Virtual Layer 2 Firewalls log the connections by default. IPS engines and Virtual IPS engines do not log the connections by default. Each individual rule can be set to override the default values.
The log levels are explained in Table 13.2
.
Table 13.2 Log Levels in Ethernet Rules
Log Level
None
Transient
Stored
Essential
Alert
Explanation
Does not create any log entry.
Creates a log entry that is displayed in the Current Events mode in the Logs view (if someone is viewing it at the moment) but is not stored.
Creates a log entry that is stored on the Log Server.
Creates a log entry that is shown in the Logs view and saved for further use.
Triggers an alert entry.
When the Log Server is unavailable, log entries are temporarily stored on the engine. When the engine is running out of space to store the log entries, it begins discarding log data in the order of importance. Monitoring data is discarded first, followed by log entries marked as Transient and Stored, and finally log entries marked as Essential. The Alert entries are the last log entries to be discarded.
The settings for storing the logs temporarily on the engine are defined in the engine's log spooling policy. For more information, see the McAfee SMC Administrator's Guide.
Note – A log entry is generated for each packet that matches an Ethernet rule. Use careful consideration when setting the logging options to avoid producing an excessive amount of log data.
134
Chapter 13 Ethernet Rules
Using Ethernet Rules
You can validate Ethernet rules and add comments to the rules just like for any other types of
rules. See Using Policy Elements and Rules (page 123) for more information.
Examples of Ethernet Rules
The examples in this section illustrate some common modifications to the default Ethernet rules and general steps on how each scenario is configured.
Logging Ethernet Protocol Use
The administrators at Company A have installed an IPS engine in Transparent Access Control mode and they want to create some custom Ethernet rules. The administrators know that the majority of traffic uses the IPv4 protocol, but they do not have a clear idea of which other
Ethernet protocols are being used in the company’s network. They decide to temporarily log the use of Ethernet protocols, excluding IPv4.
To do this, the administrators:
1. Create a new IPS Policy based on the IPS Template.
2. Add a new rule in the Ethernet rules to exclude IPv4 traffic from logging:
Table 13.3 Ethernet Rule for Excluding IPv4 Traffic from Logging
ANY
Source Destination
ANY IPv4
Service Action
Allow
Options
Logging: None
3. Add a rule to log the use of other Ethernet protocols:
Table 13.4 Ethernet Rule for Logging Ethernet Protocol Use
ANY
Source Destination
ANY ANY
Service Action
Allow
Options
Logging: Stored
4. Save and install the policy on the IPS engine.
5. View the logs generated by the matches to the Ethernet rules in the Logs view.
6. Disable the logging Ethernet rule to prevent excess log data from being generated.
Using Ethernet Rules
135
Restricting the Use of Ethernet Protocols
Now that the administrators at Company A from the previous example have a clear picture of which Ethernet protocols are being used in the company’s network, they want to restrict which protocols are allowed. The administrators determine that ARP and Spanning Tree Protocol (STP) must be allowed. Since the majority of traffic will use these protocols, the administrators do not want to log matches to the rules that allow specific protocols.
They decide to block the Cisco Discovery Protocol (CDP) on the logical interface named Inline
Interface because of the security problems it creates, and store log entries of detected CDP use.
To do this, the administrators:
1. Add a new rule in the Ethernet rules to allow ARP, Spanning Tree Protocol (STP), and IPv4 without producing any logs:
Table 13.5 Ethernet Rule for Allowing ARP and STP Use
Logical Interface Source Destination Service Action
ANY ANY ANY
ARP
STP
IPv4
Allow
Options
Logging: None
2. Add another rule to block the use of Cisco Discovery Protocol (CDP) on the Inline
Interface, and produce logs that will be stored:
Table 13.6 Ethernet Rule for Blocking CDP Use
Logical Interface Source Destination Service Action
Inline interface ANY ANY CDP Discard
Options
Logging: Stored
3. Add a rule on the last line of the Ethernet rules to block the use of other Ethernet protocols without producing logs:
Table 13.7 Ethernet Rule for Blocking Other Ethernet Protocols
Logical Interface Source Destination Service Action
ANY ANY ANY ANY Discard
Options
Logging: None
4. Save and install the policy on the IPS Engine.
136
Chapter 13 Ethernet Rules
C
H A P T E R
1 4
A
CCESS
R
ULES
Access rules are lists of matching criteria and actions that define which traffic is allowed or discarded, as well as which allowed traffic is inspected against the Inspection Policy.
The following sections are included:
Overview of Access Rules (page 138)
Configuration of Access Rules (page 138)
Examples of IPS Access Rules (page 149)
137
Overview of Access Rules
The IPv4 and IPv6 Access rules define which traffic IPS engines and Layer 2 Firewalls with Inline interfaces stop, which traffic is inspected against the Inspection Policy and which traffic is passed through without inspection. The Access rules are stored in policy elements, which are
discussed in IPS and Layer 2 Firewall Policies (page 113).
The traffic matching in Access rules is based on source IP address, destination IP address, and port information included in the packets. Additional matching criteria that is not based on information in the packets includes the day of the week and the time of day (allowing you to enforce rules during specific times, such as working hours) and the physical network interfaces the traffic is picked up from.
The Access rules provide several different ways to react when some traffic is found to match a rule. You can:
• Allow the traffic with inspection against the Inspection Policy.
• Allow the traffic without further inspection.
• Stop the traffic if the traffic passes through the inline interfaces of an IPS engine or Layer 2
Firewall with a license that allows this action.
Regardless of which of the above actions is taken, a matching rule can also create a log or alert entry.
Configuration of Access Rules
Access rules are configured on the IPv4 Access tab and the IPv6 Access tab inside IPS and
Layer 2 Firewall Policy and Template Policy elements. You can also configure Access rules on the
IPv4 Access tab and the IPv6 Access tab in IPS and Layer 2 Firewall Sub-Policy elements. You can create new IPv4 and IPv6 Access rules in the Policy Editing View, and also in the Logs view based on one or more selected log entries.
Illustration 14.1 Newly Inserted Access Rule - Main Cells
Mandatory cells for matching traffic
Engine applies Action when it finds a match
The illustration above displays an Access rule that has just been inserted into the policy. The matching cells are set to <None> to prevent the rule from having any effect on traffic in case a new rule is added to the policy accidentally. It is not necessary to modify all cells in each rule, but the mandatory cells for traffic matching (Source, Destination, and Service) must be set to some value other than <None> for the rule to be valid. The Logical Interface cell is also matched against traffic, but it is not mandatory to change its value if you want the rule to apply regardless of the interface. The other editable cells specify further conditions and options for handling connections that match the cells that are used for traffic matching.
138
Chapter 14 Access Rules
Before starting to build policies, make sure you understand the network element types available and how you can use them efficiently to define the resources that you want to protect and control. The illustration below shows the types of elements that you can use in IPv4 and IPv6
Access rules.
Illustration 14.2 Elements in Access Rules
Network and
User Elements
Protocol
Logical
Interfaces
Services QoS Class
The table below explains briefly what each Access rule cell does and which elements you can use in the rules. More information on each cell is included in the task flow later in this chapter.
The cells are presented in the default order, but you can drag and drop them to your preferred order in your own Management Client.
Table 14.1 Access Rule Cells
Cell
ID
Logical
Interface
Source
Destination
Service
Action
Explanation
(Not editable) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, the rule 14.3 is the third rule added in this policy to the insert point that is the fourteenth rule in the upper-level template.
Matches the rule based on which interface the traffic is picked up from. The same logical interface may be assigned to one or several interfaces as configured in the properties of the engine. This cell accepts only Logical Interface elements.
A set of matching criteria that defines the IP addresses and interfaces that the rule matches. Both the Source and the Destination defined must match the source and destination of a packet for the packet to match the rule. The Source and Destination cells accept any elements in the Network Elements category, as well as User and User
Group elements. Network Elements used in IPv4 Access Rules must contain IPv4 addresses, and Network Elements used in IPv6 Access Rules must contain IPv6 addresses.
The Services match a certain Protocol that defines the protocol for the traffic when it is further inspected against the Inspection Policy.
Command for the engine to carry out when a connection matches the rule, and actionspecific options for blacklisting, connection tracking, deep inspection (whether traffic is matched against the Inspection Policy), rate-based DoS protection, scan detection, and user responses.
Configuration of Access Rules
139
Table 14.1 Access Rule Cells (Continued)
Cell
QoS Class
Logging
Time
Comment
Rule Name
Hits
Explanation
The QoS Class that the engine assigns to connections that match this rule. Used in traffic prioritization and bandwidth management. The QoS Class has effect only if you set up QoS Policies.
The options for logging.
The time period when the rule is applied. If this cell is left empty, the rule applies at all times.
Your optional free-form comment for this rule. If you add a rule from the Logs view, the
Comment cell of the rule automatically includes information on the log entry which was used as the basis of the rule.
Note that you can also add separate comment rows in between rules.
Contains a rule tag and optionally a rule name.
Name: (Optional) Name or description for the rule. Displayed alongside the rule tag.
Tag: (Not editable) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @20.1). The first part of the tag is permanent and belongs to only that rule. The second part changes when the rule is changed. The first part and the second part are separated by a period.
(Not editable) Shows the number of connections that have matched the rule. This information is only shown if you have run a Rule Counter Analysis for the Policy. The cell shows “N/A” if no information is available.
Considerations for Designing Access Rules
One of the crucial issues in designing any policies is the order of the rules. The most important thing to keep in mind when editing the IPS Template Policies, IPS Policies, and IPS Sub-Policies is that the rules are read from top down. The actions Allow, Refuse, and Discard stop the processing from continuing down the Access rule table for any connection that matches the rule. Therefore, rules with any of these actions must be placed so that the more limited the rule is in scope, the higher up in the rule table it is. At its simplest, this principle means, for example, that an Access rule that allows connections to the IP address 192.168.10.200 must be put above an Access rule that stops all connections to the network 192.168.10.0/24. See
Exempting Traffic from Inspection (page 149) for a more detailed example. If the traffic does not
match any of the Access rules by the end of the policy, it is allowed by default.
140
Chapter 14 Access Rules
Default Elements
The IPS Template and the Layer 2 Firewall Template have predefined Ethernet rules, IPv4 and
IPv6 Access rules. Because the default policy elements are introduced when you import and activate a recent dynamic update package (for example, during the installation), the templates you currently have in your SMC may look slightly different from the one that is presented in this section. Newer versions of the templates work in the same way as described below. Any changes to the templates are documented in the Release Notes document for each dynamic update package.
There are several IPv4 and IPv6 Access rules with various Services defined with Continue as the action and a yellow insert point indicating the place where a Policy that uses the template can be edited.
The Access rules that you add at the insert points in custom policies based on the IPS Template or the Layer 2 Firewall Template are (in most cases) quite specific exceptions to the rules inherited from the template. For example, you could insert a rule there that allows a connection between two particular hosts to continue without any further inspection, or rules for inline IPS engines to always stop traffic between particular IP addresses and ports.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Define the Source and Destination
The Source and Destination cells specify the IP addresses that are compared to the IP addresses in each packet’s header. Based on these and other criteria, the rule is applied to matching packets. By default, these cells are set to NONE, and you must change the value in both cells to make the rule valid.
You can add more than one element in each cell. You can optionally define detailed lists of matching criteria for each cell by combining Users (stored in an integrated Active Directory database), Network Elements, DNS Domain Names, and interface Zones. Each row of the list is combined with a logical AND: all items must match for the row to match. Groups, Aliases,
Address Ranges, and Expressions are also useful for defining IP addresses in complex scenarios.
You can set the Source and Destination cells to ANY to make the rule match all possible source or destination IP addresses.
Configuration of Access Rules
141
Task 2: Define the Service
The Service cell defines which protocol(s) the rule you design applies to, which also determines the protocol used in the Inspection Policy for matching traffic (the protocol that is detected and selected for traffic by an Access rule is a matching criteria in the Inspection Policy). By default, the Service is set to <None>, and you must change the value to make the rule valid.
The Service cell accepts only Service and Service Group elements. There are ready-made
Services that cover most needs, but you may also use your own customized versions, for example, to define a non-standard port. The Services available for rule design are categorized according to protocols.
You can add more than one element in this cell to make the rule match several Services. You can optionally define detailed lists of matching criteria by combining URL Situations (for URL filtering), Applications, Services, and TLS matches. Each row of the list is combined with a logical AND: all items must match for the row to match.
Protocol Agent parameters are available for some Protocols in Service elements.
You can set the Service to ANY to make the rule match all protocols. A previous Continue rule
may define a Protocol for traffic allowed by rules that use ANY as the Service (see Configuring
Default Settings for Several Rules (page 146)). If there is no previous Continue rule that
matches the same connection that would define a Protocol of the type Protocol Agent, a rule that allows ANY Service does not apply a Protocol of the type Protocol Agent to the traffic.
Note – For the most efficient inspection, select the correct Protocol of the type Protocol
Agent when connection tracking is on (stateful inspection).
142
Chapter 14 Access Rules
Task 3: Select the Action and Action Options
The Action cell defines what happens when a packet matches the rule. The available actions are explained in Table 14.2
.
Table 14.2 Actions
Action
Allow
Continue
Discard
Refuse
Jump
Apply Blacklist
Explanation
The traffic is let through the engine.
Stores the contents of the Options cell and the Protocol option (inside the Service used) in memory and continues the inspection process. Used for setting options for subsequent rules as explained in
Configuring Default Settings for Several Rules
The traffic is silently dropped if going through an inline interface pair on IPS engine or
Layer 2 Firewall with the appropriate license.
The traffic is dropped if going through an inline interface pair on an IPS engine or
Layer 2 Firewall with the appropriate license. An ICMP error message is sent in response to notify the packet’s sender.
Matching is continued in the specified sub-policy until a match is found. If there is no matching rule in the sub-policy, the process is resumed in the main policy.
Checks the packet against the blacklist according to the options set for this rule. If the packet matches a blacklist entry and is going through an inline interface, the engine discards the connection.
Each IPv4 and IPv6 Access rule has action-specific options for blacklisting, connection tracking, deep inspection, rate-based DoS protection, scan detection, and user responses.
Table 14.3 Action Options
Action Option
Blacklisting
Connection Tracking
Deep Inspection
Rate-Based DoS
Protection
Explanation
Defines which blacklist entries are enforced for connections that match the rule based on the component that added the blacklist entry to the blacklist.
A restriction based on the blacklist sender may be necessary, for example, if the same IP address exists in two different networks. The default setting is to enforce all blacklist entries regardless of the component that created the entry. Used by rules with the Apply Blacklist action.
Defines whether the IPS or Layer 2 Firewall engine keeps a record of the
Used by rules with the Allow, Continue, or Jump action.
Defines whether matching connections are also inspected against the
Inspection rules. Used by rules with the Allow, Continue, or Jump action.
Defines whether rate-based DoS protection is enabled for traffic that matches the rule. Used by rules with the Allow, Continue, or Jump action.
Configuration of Access Rules
143
Table 14.3 Action Options (Continued)
Action Option
Scan Detection
User Response
Explanation
Defines whether scan detection is enabled for traffic that matches the rule.
Used by all rules.
Defines which automatic response is shown to the end-user when an HTTP connection is discarded. Used by rules with the Discard action.
Task 4: Select Logging Options
Rules can create a log or alert entry each time they match. By default, logging options set in a previous rule with Continue as its action are used. If no such rule exists, Layer 2 Firewalls and
Virtual Layer 2 Firewalls log the connections by default. IPS engines and Virtual IPS engines do not log the connections by default. Each individual rule can be set to override the default values.
The log levels are explained in Table 14.4
.
Table 14.4 Log Levels in Access Rules
Log Level
None
Transient
Stored
Essential
Alert
Explanation
Does not create any log entry.
Creates a log entry that is displayed in the Current Events mode in the Logs view (if someone is viewing it at the moment) but is not stored.
Creates a log entry that is stored on the Log Server.
Creates a log entry that is shown in the Logs view and saved for further use.
Triggers an alert entry.
When the Log Server is unavailable, log entries are temporarily stored on the engine. When the engine is running out of space to store the log entries, it begins discarding log data in the order of importance. Monitoring data is discarded first, followed by log entries marked as Transient and Stored, and finally log entries marked as Essential. The Alert entries are the last log entries to be discarded.
The settings for storing the logs temporarily on the engine are defined in the engine's log spooling policy. For more information, see the McAfee SMC Administrator's Guide.
Task 5: Restrict the Time When the Rule Is Enforced
Optionally, you can set a specific time period when a rule is applied using the Time cell. The validity of the rule can be set by month, day of the week, and time of day. For example, you might have certain rules that allow access only during business hours on weekdays. If you leave the
Time cell empty, the rule is always valid.
Note – The times are entered in Coordinated Universal Time (UTC), and you must adjust the times you enter to make them correspond to the engine’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).
144
Chapter 14 Access Rules
Using Access Rules
The general configuration of Access rules is explained above. The sections below provide further information on configuring Access rules:
•
Allowing System Communications
•
Configuring Default Settings for Several Rules (page 146)
•
Rematching Tunneled Packets (page 148)
•
Using Aliases in Access Rules (page 148)
For general information on using rules, see
Using Policy Elements and Rules (page 123).
Allowing System Communications
If NAT is applied to system communications, you must create Location elements and add
Contact Addresses for the elements to define which translated addresses are necessary for making contact. Only IPv4 addresses are used in system communications.
If you have inline IPS engines or Layer 2 Firewalls, be careful that you do not define rules that would prevent other SMC components from communicating with each other. The system communications are detailed in
Default Communication Ports (page 217).
There are predefined Service elements for all system communications. You can use these in your Access rules as necessary.
Using Access Rules
145
Configuring Default Settings for Several Rules
You may want to set default values for some settings in rules to avoid defining the same settings for several rules individually. The Continue action is used to set such default values.
The options that can be set using Continue rules in Access rules includes:
• The Connection Tracking options:
• The Idle Time-out option overrides the global defaults set in the IPS or Layer 2 Firewall element’s properties.
• The concurrent connection limits define the maximum number of connections allowed from a single source and/or destination IP address.
• The Protocol option inside the Service used.
• The Logging options.
When a connection matches a rule with Continue as the action, the rule’s settings are written in memory but the matching continues until another rule that matches is found. This matching rule uses the defaults set in the Continue rule unless the rule specifically overrides the defaults with different settings. This way, you do not have to define the settings for each rule separately.
You can use Continue rules to set default settings for a general type of traffic and define settings for individual rules only when specifically required. A Continue rule can be overridden by some subsequent Continue rule that has an identical scope (Source, Destination, and Service), or partially overridden by a Continue rule that partially overlaps with the previous Continue rule.
When you define Continue rules with different matching criteria, you can have several Continue rules one after another without them interfering with each other in any way at all.
Continue rules are defined in the same way as other rules. However, you must keep in mind that many or even all rules below may be affected. Options in Continue rules are used by the rules below, provided that the Source, Destination, and Service match the same connection as the
Continue rule. Continue rules are inherited from Template Policies into lower-level templates and policies like any other rules.
Sub-Policies may require special attention with Continue rules: the Sub-Policies may have different options when you insert them into different policies if the Sub-Policy rules do not override the options set by preceding Continue rules. Also, when a Sub-Policy contains a
Continue rule, the options are then used for further matching in the higher-level policy (if the processing returns to the higher-level policy).
146
Chapter 14 Access Rules
Using Continue Rules to Set Logging Options
One common use for the Continue action is to set the default log level for all subsequent rules.
Instead of setting the log level for all rules individually, you can set a Continue rule in a template or in a policy to set the default log level. The log level for any subsequent matching rules can be left undefined. The rules trigger logging as defined in the Continue rule.
Illustration 14.3 Setting the Default Log Level
In Illustration 14.3
, the default log level is set to Transient for any source, destination or service. All subsequent rules in this policy and any sub-policies log Transient by default.
Individual rules can still override this option with specific log levels, such as Essential or Stored.
If logging is not defined for a rule and there is no prior Continue rule that sets logging options, the default log level is Stored.
Using Continue Rules to Set the Protocol
Default Protocols are set using the Continue action. This way, the correct Protocol is used also for traffic that is allowed by rules that match any Service (and therefore have no particular
Service element that would set the correct protocol). The Protocol is needed to associate the traffic with the correct protocol for further inspection and to handle some types of traffic, such as FTP, correctly. The IPS Template and the Layer 2 Firewall Template include several Continue rules that associate all traffic with Protocols according to standard ports.
If you have TCP and UDP services set up in your network under non-standard ports, the traffic may not be associated to the correct protocol and be therefore inspected at a more general
(TCP or UDP) level. In this case, you can create your own custom Situation for the traffic and add it in your policy to have the traffic inspected with the correct protocol information. Only some protocols and some of their parameters are supported in the services that are used in IPS policies.
You can also add your own rules for the opposite purpose: to have some traffic not inspected as a particular protocol, but more generally as TCP or UDP traffic. In this case, you add a rule in your policy that includes the general TCP or UDP Service element from the IP-proto branch of the Services tree.
Using Access Rules
147
Rematching Tunneled Packets
If an engine inspects traffic that is tunneled using IP-in-IP tunneling or Generic Routing
Encapsulation (GRE), the traffic can be checked against IPv4 Access rules and/or IPv6 Access rules several times according to the number and type of layers in the tunnel. For example, when an IPv4 datagram contains an IPv6 datagram, the IPv4 datagram is first matched according to
Access rules. If the tunneling Service in the Access rule specifies that the encapsulated IPv6 datagram should be matched again, the contents are then matched against the IPv6 Access rules.
To limit the number of encapsulating layers, the engine properties define the maximum rematch count. By default, the maximum rematch count is 1. If this count is exceeded, the packet is allowed or discarded according to the setting specified in the engine properties and a log or an alert is generated.
Using Aliases in Access Rules
Aliases are one of the most useful tools for reducing the complexity of a policy. In a sense,
Aliases are like variables in a mathematical equation—their value changes depending on the component on which they are installed. Because Aliases are able to change their meaning to adapt to local contexts, they can be used to create a single rule that changes in meaning depending on where it is installed. Thanks to Aliases, you can use a single rule to replace multiple, near duplicate rules created separately for each engine.
To better understand this concept, let us consider an example company, which has its headquarters in Helsinki and branch offices in Atlanta, Munich, Tokyo, and Montreal. Each of these offices has its own web server. In this scenario, it seems we would require a separate rule or set of rules for each location’s web server.
By using aliases, however, we can create a single rule or set of rules that is still valid in all parts when applied on different components.
The administrator of the example company can create a web server alias,
$WebServers
. In the
Alias’s properties, the administrator defines what
$WebServers
means for each component. For the IPS engine in Helsinki, the web server would be defined as 192.168.1.101, for the IPS engine in Tokyo as 192.168.2.101, and so on.
When the administrator installs a policy containing the web server rules with the Alias, the addresses are translated to the correct address on that component. Therefore, when the policy is installed on the Helsinki IPS engine, the Alias translates to an IP address of 192.168.1.101.
The other addresses are not included in the policy that is transferred to that particular engine.
148
Chapter 14 Access Rules
Examples of IPS Access Rules
The examples in this section illustrate some common uses for Access rules and general steps on how each scenario is configured.
Exempting Traffic from Inspection
At Company A, there is an IPS engine deployed between the general office network and a subnetwork.
Illustration 14.4 Company A’s Networks
Subnetwork
Internet
Internal
Network
Log Server
Firewall IPS engine
In the subnetwork, there are several servers that provide services to the general office network as well as the Management Server and Log Server. There is also a Firewall deployed between the internal and external networks. There is heavy traffic to the subnetwork where the internal servers are, so the administrators decide to exempt the log transmissions between the Firewall and the Log Server from being inspected against the Inspection Policy to reduce the IPS engine’s workload. The administrators:
1. Create a new IPS policy based on the IPS Template to replace the Default IPS Policy that they have currently installed.
2. Add a new rule in the Access rules for their IPS engine:
Table 14.5 Access Rule for Exempting Traffic from Inspection Against the Inspection Policy
Source
Firewall
Destination
Log Server
Service
SG Engine to Log
Action
Allow
Options
Deep inspection: Off
Examples of IPS Access Rules
149
Filtering Traffic on an Inline IPS engine
Administrators at company B decide that they want more control over which hosts and ports can be used between two networks.
Illustration 14.5 Company B’s Network
Network A Network B
Administrator
Inline IPS engine
Hosts in the two networks must be able to communicate between each other using certain specific ports. Additionally, one of the administrators has a workstation connected to Network A.
The administrator’s workstation must have unrestricted access to Network B. The administrators decide that the inline IPS engine provides an acceptable level of security at this point between two internal networks.
The administrators:
1. Create elements for network A, network B, and administration host.
2. Add new Access rules for their inline IPS engine:
Table 14.6 Access Rules for Filtering Traffic
Source
Administrator
Network B
Network A
Network B
Destination
Administrator
Network B
Network A
Network B
ANY
Service
Service elements for allowed services
Action
Allow
Allow
ANY ANY ANY Refuse
Options
Logging: Undefined
Deep inspection: On
Logging: Stored
Deep inspection: On
Logging: Stored
Deep inspection: (irrelevant, because dropped traffic is never inspected further)
• Each of the first two rules allows traffic between the Source and the Destination in both directions. The order of the elements within the Source, Destination, and Service cells makes no difference to the outcome of the matching process.
• The order of the rules is important. The rules above proceed correctly from most specific to the least specific. The two first rules must be in this order, because the administrators want all connections from the Administrator host (which is in Network A) to always match the first rule and never the second one, since the rules have different logging options.
• The last of the added rules stops all traffic that is not allowed in the rules above to prevent unauthorized traffic from passing.
Note – If the inline interfaces are on a fail-open network card, traffic passes freely whenever the IPS engine is offline regardless of what the Access rules state.
150
Chapter 14 Access Rules
C
H A P T E R
1 5
I
NSPECTION
P
OLICIES
Inspection Policies define how the engines look for patterns in traffic allowed through the
Access rules and what happens when a certain type of pattern is found.
The following sections are included:
Overview of Inspection Policies (page 152)
Configuration of Inspection Policies (page 153)
Using Inspection Policies (page 160)
Example of Inspection Policies (page 161)
151
Overview of Inspection Policies
Inspection Policies define how the main traffic analysis is done for traffic that has been allowed and selected for inspection in the Access rules. The Inspection Policies are selected in IPS and
Layer 2 Firewall Policy elements, which are discussed in IPS and Layer 2 Firewall Policies
Inspection Policies examine the entire contents of the packets throughout whole connections to see if the data being transferred contains a pattern of interest. Dynamic update packages are the main source of these patterns, but you can also define new patterns as Situation elements,
which are discussed in Situations (page 105).
Virtual Security Engines select traffic for inspection, but they do not directly inspect traffic. One shared inspection process running on the Master Engine handles the inspection and correlation of traffic from all Virtual Security Engines associated with the Master Engine. Master Engines also inspect their own communications.
There are three general types of cases for using Inspection Policies:
• You can detect attempts to exploit known vulnerabilities in your systems and prevent such attempts from succeeding if the system is not patched against it.
• You can monitor traffic that does not cause alarm on the surface, but when examined for certain patterns, may turn out to conceal actual threats. For example, you can detect if a series of occasional service requests are actually someone secretly scanning the network structure or if a spike in traffic is a denial-of-service attack under way.
• You can also detect other sequences in traffic, such as the use of certain applications or even access to a particular file.
Based on the detection results, the Inspection Policy provides several different ways to react when some traffic is found to match a pattern of interest:
• Stop the traffic if it is going through an engine with inline interfaces.
• Reset the connection.
• Blacklist the connection on one or more Security Engines.
• Allow the traffic.
Regardless of which action is taken, a match can also create:
• A log entry with or without recording some of the detected traffic.
• An alert with or without recording some of the detected traffic.
152
Chapter 15 Inspection Policies
Configuration of Inspection Policies
IPS engines and Layer 2 Firewalls inspect traffic based on Situation elements, which contain the information about traffic patterns. Patterns may trigger immediate responses or just be recorded. Detected events can be matched against Correlation Situations, which combine and further analyze the traffic-based findings to detect additional threats and produce an easy-toread event stream.
Inspection Policies are selected on the Inspection tab inside IPS Policy, IPS Template Policy,
Layer 2 Firewall Policy, and Layer 2 Firewall Template Policy elements. Sub-Policies cannot contain Inspection Policies. You can add new rules to the Inspection Policy in the Policy Editing
View and also in the Logs view based on log entries.
The Inspection Policy has two parts:
• The Inspection tab contains the main rules for finding traffic patterns. The Rules tree is applied to all traffic that is not handled as Exceptions.
• The Exceptions tab contains rules that match specific portions of the traffic based on Logical
Interface, IP addresses, and Ports. Exceptions have some additional options, and can also set some of those options for the main Rules through the use of Continue rules.
The main Rules tree on the Inspection tab contains a tree of Situations, which are organized under Situation Types. This tree allows you to control which inspection checks trigger a reaction and which checks are ignored. The Rules tree defines general checks that are applied to all patterns that are not handled by a more specific definition. It is not possible to limit the scope of the checks by IP addresses or Logical Interfaces in the Rules tree.
Illustration 15.1 Inspection Tab - Rules Tree
The Exceptions are matched before the main rules. The most frequent use of Exceptions is to eliminate false positives, which typically require permitting a pattern for some part of the traffic while it still triggers a reaction when encountered in any other traffic.
Configuration of Inspection Policies
153
The illustration below shows the Exceptions panel with some rules.
Illustration 15.2 Exceptions Panel
The main matching cell is the Situation that contains the actual patterns. The other matching cells are Logical Interface, Source, Destination, Protocol, and Time. The role of the other matching cells is to limit the scope of the rule to some specific traffic, for example, to take different action based on which host is the sender or receiver of traffic identified as malicious.
The cells are explained in more detail in Exception Rule Cells (page 156).
Verifying and Tuning Inspection
The most common way to start using IPS is to start with a default policy. A general policy that is meant to work in all environments is not perfectly suited to your particular network scenario. A tuning period is needed to activate and deactivate inspection checks based on the findings and your particular needs. Tuning the policy is important, since with a small tuning effort, you can save a lot of time due to the increased relevancy and accuracy of the findings that the engine generates.
To assist in policy tuning, you can use passive termination. When passive termination is used, the engine creates a log entry that notes that a certain connection was selected for termination, but the engine does not actually terminate the connection. This allows you to check the logs and adjust your policy without the risk of cutting important business communications. There are two levels of activating this feature:
• Passive termination can be activated globally in the IPS or Layer 2 Firewall element properties for the initial policy tuning.
• Later on, you can test newly added Situations by setting individual Exception rules to passive termination mode.
For cautious introduction of new Situations introduced in dynamic update packages, you can utilize the Tags for the five most recent updates (Situations→By Tag→By Situation
Tag→Recent Updates).
Considerations for Designing Inspection Policies
The basic design principle is the same as in other rules: the rules are read from top down, and more specific rules must be placed above more general rules that match the same traffic. The detailed rules specific to some IP addresses and Protocols is defined as Exceptions. The general rules that are applied to remaining traffic are defined in the Rules tree on the Inspection tab.
The traffic matching in Inspection rules and exceptions is different from other types of rules, because it is done based on the traffic pattern definitions in Situation elements. The engines monitor the network for all patterns included in the policy. When a pattern is found, the
154
Chapter 15 Inspection Policies
Inspection rules and exceptions are matched based on the Situation element that contained the detected pattern. Inspection rules and exceptions match certain patterns only. Non-matching traffic is passed through without any reaction.
The Situation-based configuration logic means that the behavior of the Inspection rules and exceptions can change without anyone editing the policy directly. Just creating a new Situation element may include the Situation in the policy if the Situation is associated with a Situation Tag or Situation Type grouping included in the policy. For more information about Situation elements, see Situations (page 183).
Actual rules may look quite different even if they refer to the exact same Situation, since
Situations have grouping mechanisms. However, it makes no difference in matching a pattern whether you add the Situation as a single element or together with other Situations through a
Situation Tag or Situation Type.
The Permit action allows the traffic pattern and the Terminate action stops the traffic that matches the pattern. A Permit action does not unconditionally allow the traffic, because processing still continues to look for other patterns, but a Permit match does prevent the exact same Situation from matching again if it appears at any point further down in the policy.
Example Situation A matches a Permit rule with logging level set to “None”. A second rule that contains Situation A exists below the first rule in the policy with Terminate as the action and logging level set to “Stored”. The logs do not show any matches to Situation A and the traffic that matches the pattern continues uninterrupted.
Similarly, the Terminate action prevents the same Situation from matching again as the policy is processed to the end, but does not prevent other Situations from matching simultaneously.
Each Situation element is considered as a unique pattern (with the exception that is discussed below). Avoid defining the exact same pattern in different Situation elements, because such duplicates in the policy can create unintended results and makes the policies difficult to manage.
Example A Continue rule sets a User Response for Situation A, which matches the URL www.example.com. A different rule specifies Termination for Situation B, which also matches www.example.com. When the users access the URL, their connections are terminated without a User Response, because the User Response is set for Situation A and the traffic is terminated by Situation B. The configuration handles these as two separate patterns.
The exception where one Situation is specifically used in the configuration to prevent a different
Situation from matching is URL filtering. When you whitelist URLs, the special URL filtering
Situations stop further URL-based matching.
Example A URL filtering category defined in Situation A prevents users from accessing www.example.com (among other sites). The administrators add www.example.com to a custom Situation B that is permitted higher up in the policy. Users can now access www.example.com. With other types of Situations, matching connections would continue to be terminated if two different Situations were used.
Configuration of Inspection Policies
155
Exception Rule Cells
The table below explains briefly what each Exception rule cell does.
Table 15.1 Exception Rule Cells
Cell
ID
Situation
Logical
Interface
Severity
Source
Destination
Protocol
Action
Logging
Time
Comment
Explanation
(Not editable) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, rule 1.3 is the third rule added in this policy to the insert point that is the first
Inspection rule in the upper-level template.
Defines the patterns of traffic that the rule matches. In addition to individual Situation elements, this cell may contain Situation Type and Tag elements, which are shown as branches in the Situations tree and allow adding the whole branch of Situations at once to a rule.
Limits the rule based on which interface the traffic is picked up from. The same logical interface may be assigned to one or several interfaces as configured in the properties of the IPS engine. This cell accepts only Logical Interface elements.
Limits the rule to those matching Situations that have a severity value within a range you define. This is most useful with rules that include Situation Tags in the Situation cell.
Limit the IP addresses that the rule matches, for example, to create different responses to the same pattern depending on the communicating hosts. The Source and Destination cells accept any elements in the Network Elements branch.
Limits the Protocols that the rule matches. The protocol is set for traffic in the Access rules in the Service cell of the rule that allows the traffic. The Protocol cell allows you to limit the scope of an Inspection rule based on the protocol that an Access rule has assigned.
Command for the engine to carry out when a connection matches the rule. Actionspecific options for blacklisting, connection termination, and user response.
The Continue action can be used to set action-specific Action Options for Exceptions and
(depending on the option) for the Rules tree as explained in Setting Default Options for
Several Inspection Exceptions (page 160).
Options for logging.
Limits the time period when the rule is applied. If the cell is empty, the rule applies at all times.
Your free-form comment for this rule. If you add a rule from the Logs view, the Comment cell of the rule automatically includes information on the log entry which was used as the basis of the rule.
Note that you can also section the rules under comment rows.
156
Chapter 15 Inspection Policies
Table 15.1 Exception Rule Cells (Continued)
Cell
Rule Name
Explanation
Contains a rule tag and optionally a rule name.
Name: (Optional) Name or description for the rule. Displayed alongside the rule tag.
Tag: (Not editable) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @20.1). The first part of the tag is permanent and belongs to only that rule. The second part changes when the rule is changed. The first part and the second part are separated by a period.
Default Elements
There are several Inspection Policy templates, which are introduced when you import and activate a dynamic update package. The rules in the Inspection Policy templates may change when you activate new update packages. The table below lists the default Inspection Policy template elements.
Table 15.2 Default Inspection Policy Template Elements
Template
Empty Inspection
Policy
Description
Inspection Policy with a set of Inspection rules that do not enforce inspection.
Loose Inspection
Policy
Strict Inspection
Policy
Customized Strict
Inspection Policy
Inspection Policy with a set of Inspection rules for detecting common threats.
Loose Inspection Policy logs Situations categorized as Suspected Attacks but allows the traffic to pass.
Inspection Policy with a set of Inspection rules for detecting common threats.
Strict Inspection Policy terminates Suspected Attacks with an alert.
Strict Inspection Policy is suitable as the initial policy in most environments. The
Strict Inspection Policy terminates a connection if the engine cannot see the whole connection. It is recommended that you use the Strict Inspection Policy as a starting point for your Inspection Policies.
Inspection Policy that is based on the Strict Inspection Policy and contains a set of customized Inspection rules.
Customized Strict Inspection Policy was used when the IPS was tested at ICSA
Labs and NSS Labs. It provides an example of a customized Inspection Policy.
Configuration of Inspection Policies
157
158
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Note – Keeping your system up-to-date with latest dynamic updates is an essential part of maintaining your Inspection Policies. See the Management Client Online Help for information on dynamic updates and instructions for enabling automatic update download and activation.
Task 1: Create an Inspection Policy
To customize inspection, you must have a custom Inspection Policy element. The pre-defined templates are a good starting point for your own customizations. Policy elements are discussed
in detail in IPS and Layer 2 Firewall Policies (page 113).
Task 2: Activate Deep Inspection in IPS and Layer 2 Firewall Policies
Typically, you introduce deep inspection after creating and testing initial Access rules. You must specifically activate deep inspection for the portion of traffic that you want to deep inspect. This is done in the Access rules. See Access Rules (page 99) for more information. You also select which Inspection Policy is used for deep inspection on the Inspection tab of the IPS or Layer 2
Firewall Policy.
Task 3: Activate the Relevant Inspection Checks
Traffic patterns of interest are defined in Situations, so the inspection checks are based on selecting the desired reaction to the Situations when the pattern is found in network traffic. It is not mandatory to create any additional Situations to activate inspection checks, since there are many default Situation elements and they are continuously updated through dynamic update packages.
The Rules tree on the Inspection tab is the main tool that allows you to select which traffic patterns are permitted and stopped, whether a log entry or an alert is triggered, and whether matching traffic is recorded. All Rules in the Rules tree can be edited, including overrides that have been set in a higher-level template. The Rules tree can contain a maximum of one instance of each Situation to prevent the definitions within the Rules tree from overlapping.
Task 4: Define the Exceptions
The Exceptions tab allows you to create detailed rules, which are processed before the Rules tree definitions on the Inspection tab. The Exceptions have additional features compared to the
Rules tree:
• You can make exceptions to the general Rules tree definitions based on Source, Destination, and Protocol information.
• You can set options for connection termination (including User Responses) in addition to the options that are available in the Rules tree. The Response options define an automatic client notification for any HTTP connection that is terminated.
• You can create Continue rules to set Action Options and general rule Options for other
Exceptions and the Rules tree. The Rules tree contains specific definitions for logging, so the logging options set with Continue rules do not affect traffic that matches the Rules tree.
Chapter 15 Inspection Policies
• You can create rules in Inspection Policy templates that cannot be changed in the inheriting policies.
• You can create rules that are applied only on certain days and/or times of day.
In addition to individual Situation elements, the Situation cell may contain Tag and Situation
Type elements, which are shown as branches in the Situations tree and allow adding the whole branch of Situations at once to a rule. Most of the Situations you add to the Exceptions are those that you consider false positives in your environment (for example, Situations for exploit attempts against an operating system that is not used in your organization).
In the Exceptions, it is highly unusual to set the Situation cell to ANY. This is not useful in most cases because the patterns that Situations define range widely from Situations that detect something as benign as the use of particular applications to something as malicious as successful attacks on a servers. This also creates unnecessary load on the engines, as a high number of Situations is checked in each matching connection.
Task 5: Eliminate False Positives
As the Inspection rules and exceptions are matched to traffic, there are always some occurrences of false positives (matches that are incorrect or irrelevant in your environment). By tuning the Inspection Policy to the actual traffic and applications in your network environment, you can increase the relevance of inspection results greatly. To eliminate a false positive, you adjust either the Inspection Rules tree or the Exceptions depending on whether the change should be applied globally or to traffic between specific hosts. An easy way to create new
Exceptions is to use an existing log entry as the basis: you can create Exceptions through the right-click menu of log entries. See the
Eliminating a False Positive (page 161) example for a
practical overview of one approach to eliminating a false positive.
Task 6: Add Custom Inspection Checks
If you want to detect some pattern in traffic that is not defined in the predefined Situations (for example, a particular internal file server in your network being accessed) or if you want to create a modified version of some existing Situation, you can create a new Situation element. This is explained in
Configuration of Situations (page 106). You can add your custom Situations to the
Rules tree by selecting a Situation Type for them.
Configuration of Inspection Policies
159
Using Inspection Policies
For general information on using rules, see
Using Policy Elements and Rules (page 123).
Setting Default Options for Several Inspection Exceptions
You may want to set default settings for some Exception rules to avoid defining the same settings for several rules individually. The Continue action in Exception rules is used to set such
default options in the same general way as in the Access rules. See Configuring Default
Settings for Several Rules (page 146). In Exception rules, all settings in the Action Options and
the Logging cell can be set using Continue rules. However, the Rules tree on the Inspection tab ignores any logging options set with Continue rules. In the Rules tree, the rules either inherit the logging settings from a higher level in the tree or define a specific logging option as an override.
Importing Snort Rules Libraries
You can import rule definitions from an existing Snort rules library (
.rules
) files. Importing a
Snort rules library creates a new Inspection Policy. Each Snort rule is converted into a Situation element and an Exception rule in the Inspection Policy:
• The Action and Source/Destination Network parameters in the Snort rules are used to define the Exception rule.
• The Snort rule options are used to define the Situation element. The Situation element is used in the corresponding Exception rule.
The original Snort rule is included as a comment in the Context of the Situation. For more
information about Situation elements, see Situations (page 105).
160
Chapter 15 Inspection Policies
Example of Inspection Policies
The example in this section illustrates a common modification to the Inspection Policy and general steps on how the scenario is configured.
Eliminating a False Positive
The administrators in this example have just started using Inspection rules. They have installed a policy that includes only the rules defined in the Loose Inspection Policy. When they install the
IPS Policy, they soon start receiving alerts.
After some investigation, the administrators realize that the alert is caused by a custom-built application, which communicates in a way that happens to match the pattern of how a certain exploit would be carried out by an attacker. The custom-built application is only used by a specific server and a few clients in the internal network, so they quickly modify the Inspection
Policies to exclude those particular hosts for the Situation in question. The administrators:
1. Create Host elements to represent the server and the clients.
2. Create a Group element that includes the client’s Host elements.
• The administrators name the Group so that it is immediately clear from the name that the
Group contains those hosts that must contact the server running their custom-built application. This makes the new rule easier to read than if they included the hosts directly in the rule.
3. Add the following rule on the Exceptions tab in their Inspection Policy:
Table 15.3 Rule for Eliminating a False Positive
Situation
The Situation element that is mentioned in the alerts in the Logs view.
Source
The Group defining the clients.
Destination
The Host for the internal server.
Action Logging
Permit None
• If the Situation matches traffic between any other hosts than those included in the Group, the IP address does not match those defined in the new rule, so the processing will continue to the next rule, which terminates the traffic and triggers an alert.
• The logging would not have to be set to None, because it is the default option, but the administrators want to do so anyway to make sure any rules they add in the future cannot accidentally set logging on for this rule.
4. Refresh the policy on the IPS engines.
Example of Inspection Policies
161
162
Chapter 15 Inspection Policies
C
H A P T E R
1 6
P
ROTOCOL
A
GENTS
Protocols of the Protocol Agent type are special modules for some protocols and services that require advanced processing. Protocol Agents can enforce policies on the application layer.
The following sections are included:
Overview of Protocol Agents (page 164)
Configuration of Protocol Agents (page 165)
Using Protocol Agents (page 167)
Examples of Protocol Agent Use (page 171)
163
Overview of Protocol Agents
Protocol Agents are software modules for advanced processing of some protocols that require special handling on the Layer 2 Firewall or the IPS engine due to their complexity, address information in the data payload, related connections, etc. Protocol elements also associate the traffic with a certain protocol for inspection against the Inspection Policy.
Protocol Agents on Layer 2 Firewalls and IPS engines can:
• Validate application-level protocol use (for example, FTP command syntax).
• Open related connections when required (for example, FTP data connections).
Some protocols always require the use of the correct Protocol Agent to pass inspection by the
Layer 2 Firewall or the IPS.
Connection Handling
When related new connections are opened based on information exchanged in an initial connection, Protocol Agents may be needed. Protocol Agents are provided to handle the following protocols:
• FTP with related active and passive data connections.
• Microsoft RPC (MSRPC) for Microsoft Exchange and Outlook communications.
• NetBIOS for the Windows NetBIOS datagram services.
• Oracle TNS protocol communications.
• Remote Shell protocol communications.
• SunRPC portmapper communications.
• TFTP file transfers.
Example File Transfer Protocol (FTP) uses two related connections: a control connection and a separately established data connection. If the control connection is allowed without the
Protocol Agent, the IPS engine does not recognize that the data connection is part of an existing connection and handles it as a new connection (which usually leads to failed data transfer).
Protocol Validation
Protocol Agents can be used to validate communications against standards of specific protocols. Exactly how this works depends on the protocol in question.
A few examples:
• The FTP Protocol Agent can be set to strictly limit the allowed commands within the control connection to standard commands as listed in the FTP specifications. If other commands are sent in the control connection, the connection is dropped.
• The Oracle Protocol Agent can control the size of the Oracle TNS packets, or the location of the Listener service with respect to the database services.
• The SSH Protocol Agent can ensure that the SSH handshake is performed at the beginning of an SSH connection.
164
Chapter 16 Protocol Agents
Configuration of Protocol Agents
Protocol Agents are represented in the Management Client by Protocol elements that have
Protocol Agent as their type. Other Protocol elements are of the type Protocol Tag.
Illustration 16.1 Using Protocol Agents
Protocol
Agent
Service Access
Rules
Protocol Agents are not included directly in IPS policies or Layer 2 Firewall Policies. They are used inside custom Service elements that you create. The custom Service elements are used in
Access rules. Whenever traffic matches a rule that contains a Service element with an associated Protocol Agent, the Protocol Agent is automatically activated.
All Protocol Agents are default elements, and you cannot change them or add any new ones.
There are also default Service elements for most supported protocols that you can use to activate the Protocol Agents. However, some Protocol Agents have parameters and options you can set by creating customized Services as explained below.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help or the McAfee SMC
Administrator’s Guide PDF.
Task 1: Create a Custom Service with a Protocol Agent
There are default Service elements that refer to Protocol Agents. These default Services can be used without additional configuration in the Access rules. However, the default Services do not allow you to change the default parameters of Protocol Agents that have configurable parameters. If you want to modify the way a Protocol Agent behaves, you must create a new custom Service of your own and attach the correct Protocol Agent to that Service. The Service element contains the identifying information, such as a port number, that determines which traffic the Service matches. In most cases, this alone ensures that the Protocol Agent is not applied to the wrong type of traffic.
Task 2: Set Parameters for the Protocol Agent
If you create your own custom Service that uses a Protocol Agent that has configurable parameters, you can specify parameters for the Protocol Agent in the properties of the Service.
The Protocol Agents are listed in
Using Protocol Agents (page 167). See the Management Client
Online Help or the McAfee SMC Administrator’s Guide PDF for information on the parameters for the Protocol Agents.
Configuration of Protocol Agents
165
Task 3: Insert the Service in Access Rules
Whether you create a custom Service or use one of the predefined Services that have a Protocol
Agent attached to them, you must define the traffic the Protocol Agent handles in the Access rules in your Layer 2 Firewall Policies or IPS Policies.
A Protocol Agent can be set either on a rule-by-rule basis, or you can create a rule with Continue as the rule’s Action. When there is a Continue rule, rules further down in the rule table that match the same traffic (same source and destination) use the Protocol Agent defined in the
Continue rule. With Protocol Agents, the Continue rule affects only rules where the Service cell is set to ANY. More specific Service definitions override the Continue rule, as all Service elements specify that either some particular Protocol Agent or no Protocol Agent is used. Some protocols may require a Protocol Agent if the Connection Tracking option is enabled for the rule.
Those protocols may not be allowed by a rule that has ANY as its Service unless a Protocol
Agent is configured using a previous matching Continue rule.
Since Protocol Agents validate traffic against the specifics of a particular protocol, you must ensure that a Service with a Protocol Agent is not applied to traffic that does not use that protocol. Also, Protocol Agents are designed for particular types of uses, so they may not always be appropriate even if the protocol matches. See below for details of what each Protocol Agent does.
166
Chapter 16 Protocol Agents
Using Protocol Agents
There are Protocol Agents for many different protocols. This section describes the available
Protocol Agents and lists the configurable parameters that they add to Services that use them.
When the description below states “There are no configurable parameters for this Protocol
Agent”, the Protocol Agent does not have any options, but may still have a control for turning the
Protocol Agent on/off in the Service.
FTP Agent
One of the most common ways to transfer files across networks is using FTP. An FTP session starts with a control connection (by default, TCP port 21), and the data connection continues using a dynamically allocated port. The Protocol Agent keeps track of the actual ports used so that ports can be opened only as needed for specific connections. This way, the whole range of possible dynamic ports does not need to be allowed in the policy. The FTP Protocol is platformindependent.
This agent has parameters you can set in the Service properties.
GRE Agent
The Generic Routing Encapsulation (GRE) protocol is a tunneling protocol that allows the encapsulation of network layer packets inside IP tunneling packets. The GRE agent provides protocol inspection for tunneled GRE traffic. This agent specifies rematching parameters for
GRE-encapsulated packets, and defines which traffic is tunneled. This agent has parameters you can set in the Service properties.
GTP Agent
The GPRS Tunneling Protocol (GTP) is used to carry GPRS (general packet radio service) packets in GSM, UMTS, and LTE networks. The GTP agent provides protocol inspection for GTP traffic.
There are no configurable parameters for this Protocol Agent.
H.323 Agent
H.323 defines a set of protocols as well as the components and procedures for real-time multimedia communication. H.323 consists of a series of different types of standards related to video and audio services, real-time transport, control channels, security, etc.
There are no configurable parameters for this Protocol Agent.
HTTP Agent
The HTTP agent can be used to log the URLs from HTTP requests. This agent has parameters you can set in the Service properties.
HTTPS Agent
The HTTPS agent can be used for identifying encrypted HTTPS traffic for decryption and inspection in the Access rules, and for identifying encrypted HTTPS traffic for inspection in the
Inspection policy. This agent has parameters you can set in the Service properties.
Using Protocol Agents
167
IPv4 Encapsulation Agent
The IPv4 Encapsulation Agent provides protocol inspection for tunneled IPv4 traffic. This
Protocol Agent specifies rematching parameters for IPv4 packets encapsulated in IPv6 packets.
This agent has parameters you can set in the Service properties.
IPv6 Encapsulation Agent
The IPv6 Encapsulation Agent provides protocol inspection for tunneled IPv6 traffic. This
Protocol Agent specifies rematching parameters for IPv6 packets encapsulated in IPv4 packets.
This agent has parameters you can set in the Service properties.
MGCP Agent
The MGCP (Media Gateway Control Protocol) agent provides support for related RTP (Real-time
Transport Protocol) connections in VoIP (Voice over IP) traffic. There are no configurable parameters for this Protocol Agent.
MSRPC Agent
The MSRPC Protocol Agent is primarily meant for communications between Microsoft Outlook clients and a Microsoft Exchange server.
The supported end-point mapper (EPM) connection method between the Outlook client and the
Exchange server is TCP. By default, the Microsoft RPC/EPM service is available at port 135/TCP and the communications continue using a dynamically allocated port. This Protocol Agent keeps track of the actual ports used, so that the range of dynamic ports does not need to be allowed in the policy.
There are no configurable parameters for this Protocol Agent.
NetBIOS Agent
This Protocol Agent provides deep inspection for Windows NetBIOS Datagram Service connections. This agent is also used to allow Windows NetBIOS Datagram Service connections through the Layer 2 Firewall. There are no configurable parameters for this Protocol Agent.
Oracle Agent
This Protocol Agent handles Oracle Transparent Network Substrate (TNS) protocol-based
SQL*Net, Net7, and Net8 connections. It is meant for cases where TCP port 1521 is used only for negotiating the port number for Oracle database connections, and the port number for the actual connection is assigned dynamically.
This Protocol Agent is needed only if the database is located on a different computer than the
Oracle listener. The Oracle Protocol Agent does not modify payload data because the database service connections may go through a different route than the listener connection. You can create custom Oracle agents with different settings when required.
168
Chapter 16 Protocol Agents
RTSP Agent
The RTSP (Real Time Streaming Protocol) network control protocol is used for establishing and controlling media sessions between clients and media servers. The RTSP Protocol Agent allows
RTP (Real-time Transport Protocol) and RTCP (Real-time Control Protocol) media streaming connections initiated with RTSP through the engine. This agent has parameters you can set in the Service properties.
SCCP Agent
The SCCP (Skinny Call Control Protocol) provides support for related RTP (Real-time Transport
Protocol) connections in VoIP (Voice over IP) traffic. There are no configurable parameters for this Protocol Agent.
Services in Firewall Agent
This Protocol Agent is used with services running on Firewalls managed by the same
Management Server as the Layer 2 Firewall or IPS engine. It is only intended for the system’s internal use. There are no configurable parameters for this Protocol Agent.
Shell Agent
Remote Shell is a widely used remote management protocol. This Protocol Agent manages
Remote Shell connections and RExec connections. RExec is a remote protocol with which it is possible to run commands on another computer. This agent has parameters you can set in the
Service properties.
SMTP Agent
The Simple Mail Transfer Protocol (SMTP) Protocol Agent provides protocol validation and deep inspection. There are no configurable parameters for this Protocol Agent.
SSH Agent
Secure Shell (SSH) is an encrypted remote use protocol. This Protocol Agent validates the communications to make sure the protocol used really is SSH. The SSH Agent validates SSHv1 only. There are no configurable parameters for this Protocol Agent.
Using Protocol Agents
169
SunRPC Agent
The Sun Remote Procedure Call (RPC) Protocol Agent only assists the Layer 2 Firewall or IPS engine in Portmapper connections. It makes the handling of RPC program numbers used in the
Access rules faster. Only Portmapper connections going through the Layer 2 Firewall or IPS engine are assigned this Protocol Agent. This Protocol Agent is not intended for other communications.
The SunRPC Protocol Agent collects information about RPC services by interpreting the GET
PORT and DUMP PORTS requests and their respective answers. All information it collects is stored in the Portmapper cache.
When the packet filter needs to evaluate RPC matches, it consults the Portmapper cache to check if the destination of the packet has the appropriate service defined in the rule. If the cache does not have the requested information available, the packet under evaluation is not let through and a query is sent to the destination host for RPC information. The information received is stored in cache.
There are no configurable parameters for this Protocol Agent.
TCP Proxy Agent
The TCP Proxy Agent is used for TCP connections that need to be closed after a certain amount of idle time. Certain TCP-based applications do not properly handle the closing of connections, and leave them open for a long period of time, unnecessarily consuming resources. For such situations, the TCP Proxy Agent can be used to actively close the connections after a certain idle time. In addition, the TCP Proxy Agent may abort a connection if the closing of the connection does not complete in a specified period of time.
There are no configurable parameters for this Protocol Agent.
TFTP Agent
The Trivial File Transfer Protocol (TFTP) Agent performs data transfer from a server to a client using dynamically selected ports. There are no specific limits to the port range in the TFTP protocol (RFC 1350).
A TFTP Agent is attached to a UDP connection established between the client and the server.
The client opens the control connection from a dynamically selected source port to the fixed destination port 69/UDP on the server. A separate UDP data connection is established between the client and the server after the client has sent a read or write command to the server. The server opens a data connection from a dynamic source port to the client’s destination port, which is the same as the one used as the source port of the control connection.
There are no configurable parameters for this Protocol Agent on the IPS.
170
Chapter 16 Protocol Agents
Examples of Protocol Agent Use
The examples in this section illustrate some common uses for Protocol Agents and the general steps on how each scenario is configured.
Preventing Active Mode FTP
Company A has an FTP server that allows access from the Internet. According to company policy, the IPS engine must restrict users to passive mode FTP connections.
The administrators:
1. Create a new Service element for passive FTP.
2. Attach the FTP Protocol Agent to the Service.
3. Change active mode FTP setting to No in the Service properties.
4. Create an Access rule that allows users to connect to the FTP server using their custommade Service element.
5. Refresh the policy on the IPS engine.
Logging URLs Accessed by Internal Users
Company B has decided to keep track of which web pages the employees visit. In addition to logging the connections, the administrators also want to log URLs. The access is currently controlled by an Access rule that allows all outbound connections from the internal networks to the Internet regardless of the service, so the administrators decide to add the HTTP Protocol
Agent in a Continue rule.
The administrators:
1. Add the Continue rule above the existing Access rule:
Source
Internal Networks
Internal Networks
Destination
Expression
“NOT Local Protected Sites”
Expression
“NOT Local Protected Sites”
Service
“HTTP (with URL Logging)”
Service
ANY
Action
Continue
Allow
• Using the “NOT Local Protected Sites” expression requires the Alias “Local Protected
Sites” to be configured with a translation value for the IPS engine in question.
2. Refresh the policy on the IPS engine.
Examples of Protocol Agent Use
171
172
Chapter 16 Protocol Agents
C
H A P T E R
1 7
TLS I
NSPECTION
The TLS Inspection feature decrypts TLS connections so that they can be inspected for malicious traffic, and then re-encrypts the traffic before sending it to its destination.
The following sections are included:
Overview of TLS Inspection (page 174)
Configuration of TLS Inspection (page 175)
Using TLS Inspection (page 178)
Examples of TLS Inspection (page 179)
173
Overview of TLS Inspection
HTTPS is used to secure HTTP connections. When a web browser connects to a server that uses
HTTPS, the browser and the server negotiate an encryption algorithm, which is used to create the encrypted connection. The server sends a certificate that is signed by a certificate authority to authenticate its identity to the web browser.
However, the encrypted HTTPS connection can also be used to obscure web-based attacks. TLS
Inspection allows you to decrypt HTTPS traffic so that it can be inspected.
Strict TCP inspection mode is automatically applied to TCP connections when TLS inspection is
used. See TCP Modes for Deep Inspection (page 60) for more information.
The TLS Inspection feature consists of server protection, which inspects incoming connections to servers in the protected network, and client protection, which inspects HTTPS outgoing connections initiated by clients in the protected network.
When a TLS server in the internal network is the destination of an incoming connection, the engine uses the server's credentials to decrypt and re-encrypt the traffic. When a client in the internal network initiates a connection to an external TLS server, the engine checks whether the server’s certificate was signed by a certificate authority that is considered trusted. If the certificate was signed by a trusted certificate authority, the engine makes a new certificate that matches the server's certificate. From the point of view of a user in the internal network, the process is invisible: the connection is established in the same way as a connection made directly to a TLS server.
When a server’s certificate is self-signed or has not been signed by a trusted certificate authority, the engine cannot trust the server certificate. In this case the engine makes a new self-signed certificate. This certificate is presented to the user in the internal network, and the user’s browser shows the same warning it would show if it received a self-signed certificate directly from a TLS server. In this case, the user must decide whether or not to accept the certificate.
In both cases, the engine adds a Netscape Certificate Comment to the Extensions in the certificate to indicate that the certificate is a dynamically created certificate for SSL/TLS deep inspection. Substituting the original server certificate allows the engine to decrypt and reencrypt the traffic.
After decrypting the traffic, normal HTTP inspection is applied, and if the traffic is allowed to continue, it is re-encrypted before forwarding it.
174
Chapter 17 TLS Inspection
Configuration of TLS Inspection
Illustration 17.1 Elements in TLS Inspection
Custom TCP Service
Server
Credentials
HTTPS Inspection
Exceptions
Client Protection
Certificate Authority
Access Rules TLS Match
IPS / Layer 2
Firewall Engine
The Server Credentials and the Client Protection Certificate Authority are specified in the properties of the engine that provides TLS Inspection. The engine uses the private key and certificate stored in the Server Credentials to decrypt traffic to and from HTTPS servers in the protected network for inspection.
The Client Protection Certificate Authority contains a private key and a certificate. The engine uses the private key stored in the Client Protection Certificate Authority to sign the certificates presented to the end-user, and the certificate to negotiate encrypted connections with TLS servers.
TLS Match elements define matching criteria for the use of the TLS protocol in traffic, and allow you to prevent specified traffic from being decrypted. TLS Matches that deny decrypting are applied globally, even if the TLS Match elements are not used in the policy.
The HTTPS Inspection Exceptions element is a list of domains that are excluded from decryption and inspection. The HTTPS Inspection Exceptions can be specified in the Protocol Parameters of a custom HTTPS Service, which is used in the Access rules to select HTTPS traffic for inspection.
The Access rules define which traffic is decrypted and inspected. You can select specific traffic for decryption and inspection, or you can enable the decryption and inspection of all TLS traffic.
Once a certificate for client and/or server protection has been uploaded to the engine, it is possible to unintentionally enable TLS decryption for all traffic in one of the following ways:
• Adding an Application that allows or requires the use of TLS to an Access rule
• Enabling the logging of Application information in the Access rules
• Enabling Deep Inspection in an Access rule with the Service cell of the rule set to ANY.
Configuration of TLS Inspection
175
Default Elements
The Default HTTPS Inspection Exceptions element is an HTTPS Inspection Exceptions element that excludes domains used by the Security Management Center and engines from decryption and inspection. You cannot edit the Default HTTPS Inspection Exceptions element. If you need to make changes, you can duplicate the Default HTTPS Inspection Exceptions element and edit the copy.
The default HTTPS (with decryption) Service element enables the decryption of HTTPS traffic that uses the default port 443, excluding the domains that are specified in the Default HTTPS
Inspection Exceptions. You cannot edit the default HTTPS (with decryption) Service element. If you need to make changes, you can duplicate the HTTPS (with decryption) Service element and edit the copy.
There are predefined Trusted Certificate Authority elements that represent the signing certificates of major certificate authorities. Default Trusted Certificate Authority elements are automatically added from dynamic update packages and cannot be edited or deleted. When client protection is used, the engine checks whether the certificate of an external server was signed by one of the Trusted Certificate Authorities. You can also create your own Trusted
Certificate Authority elements to represent other certificate authorities that the engine should consider trusted.
Configuration Workflow
The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Create Server Credentials Elements
If you want to inspect TLS traffic for which an internal server is the destination, you must create a Server Credentials element to store the private key and certificate of the server. The private key and certificate allow the engine to decrypt TLS traffic for which the internal server is the destination so that it can be inspected.
Task 2: Create Client Protection Certificate Authority Elements
If you want to inspect TLS traffic between a client in the internal network and an external server, you must create a Client Protection Certificate Authority element that contains the credentials the engine uses to sign the certificate it generates. You can import an existing private key and certificate, or generate a new private key and certificate.
You must configure users’ web browsers to trust certificates signed using the credentials in the
Client Protection Certificate Authority element to avoid excessive warnings or error messages about invalid certificates.
176
Chapter 17 TLS Inspection
Task 3: Exclude Traffic From Decryption and Inspection
Traffic to and from some servers that use TLS may contain users’ personal information that is protected by laws related to the privacy of communications. Decrypting and inspecting this traffic may be illegal in some jurisdictions. You can optionally exclude traffic from decryption and inspection in two ways: globally with a TLS Match element, or for specific matching traffic with an HTTPS Inspection Exception element.
TLS Matches define matching criteria for the use of the TLS protocol in traffic, and allow you to prevent specified traffic from being decrypted. TLS Matches that deny decrypting are applied globally, even if the TLS Match elements are not used in the policy. However, TLS Match elements that are used in specific Access rules can override globally-applied TLS matches.
In most cases, TLS Matches are the recommended way to prevent traffic from being decrypted and inspected. Globally excluding domains from decryption may also prevent some Applications from being detected in encrypted connections. In this case, you can use HTTP Inspection
Exceptions exclude the domain from TLS inspection.
HTTPS Inspection Exceptions are used in a custom HTTPS service to define a list of domains for which HTTPS traffic is not decrypted. The custom HTTPS service must be used in a rule, and only traffic that matches the rule is excluded from decryption and inspection. HTTPS Inspection
Exceptions are primarily intended for backwards compatibility.
Task 4: Activate TLS Inspection
In the engine properties, you specify the Client Protection Certificate Authority (if you want to inspect traffic between internal clients and external servers), and the Server Credentials (if you want to inspect traffic for which an internal server is the destination). Depending on the options you specify, you can configure only client protection, only server protection, or both client and server protection.
Note – Once a certificate for client and/or server protection has been uploaded to the engine, it is possible to unintentionally enable TLS decryption for all traffic by adding an
Application that allows or requires the use of TLS to an Access rule, enabling the logging of Application information in the Access rules, or enabling Deep Inspection in an Access rule with the Service cell of the rule set to ANY.
If the default HTTPS (with decryption) Service element meets your needs, you can use the default HTTPS (with decryption) Service element in the Access rules without modification. You must create a custom HTTPS Service in the following cases:
• You want to enable decryption for HTTPS traffic that uses a different port.
• You want to select a different HTTPS Inspection Exceptions element.
• You want to log the URLs in matching traffic.
• You want to modify any of the other settings in the Service Properties.
The Access rules define which traffic is decrypted and inspected. To select specific traffic for decryption and inspection, you create Access rules that enable Deep Inspection and use a custom HTTPS Service or the default HTTPS (with decryption) Service element. To enable the decryption and inspection of all TLS traffic, you enable Deep Inspection in an Access rule with the Service cell of the rule set to ANY. Traffic that matches the Access rule is decrypted and inspected in the same way as unencrypted HTTP traffic according to the Inspection rules. See
Access Rules (page 137) for more information about the Access Rules.
Configuration of TLS Inspection
177
Using TLS Inspection
The general configuration of TLS Inspection is explained above. This section provides further information on configuring TLS Inspection.
Security Considerations
Because the HTTPS communications mediated by the engine are decrypted for inspection, and because the private keys of the servers are stored in the Server Credentials elements on the
Management Server, you must carefully consider security precautions when using TLS
Inspection. The following recommendations are general guidelines for ensuring the security of the engine and the SMC:
• Run the Management Server on a hardened operating system.
• Disable SSH access to the engine’s command line if it is not needed regularly.
• Ensure that the engine’s Control interface is in a controlled network.
• Save Management Server backups as encrypted files.
Engine Deployment
TLS Inspection requires two separate secure connections: one from the client to the engine, and one from the engine to the server. For this reason, engines must be deployed in inline mode to use TLS Inspection. TLS Inspection cannot be done for traffic picked up through Capture interfaces.
TLS inspection cannot be used on redundant single inline engines deployed alongside a Firewall cluster using dispatch clustering. In dispatch clustering, traffic is received by one node in the
Firewall cluster. The node forwards the traffic to the other Firewall nodes. This can result in a situation where one of the single inline engines only receives one direction of the traffic and the other single inline engine receives both directions of the traffic. If one engine has created substitute certificates, and traffic is dispatched through a different engine without passing through the engine that created the substitute certificates, the connection fails.
For more information about engine deployment, see
NGFW Deployment in IPS and Layer 2
URL Filtering Decrypted TLS Traffic
Once TLS traffic has been decrypted, URL filtering (license-controlled feature) can be done in the same way as for regular traffic. Any traffic that is allowed to continue after URL filtering is reencrypted and sent to its destination. For more information about how URL filtering works, see
178
Chapter 17 TLS Inspection
Examples of TLS Inspection
The examples in this section illustrate some common uses for TLS Inspection and general steps on how each scenario is configured.
Server Protection
Company A’s web server offers HTTPS services to their customers. The administrators want to be able to detect and block attacks targeting the HTTPS server that are encrypted inside an SSL tunnel. They decide to configure TLS Inspection to decrypt and inspect traffic to and from the
HTTPS server.
The administrators do the following:
1. Create a Server Credentials element and import the private key and certificate of the
HTTPS server.
2. Select the Server Credentials in the engine properties.
3. Create Access rules with the default HTTPS (with decryption) Service as the Service.
4. Use the Inspection rules from the IPS Template to look for attacks in HTTP traffic.
5. Save and install the policy.
Client Protection
The administrators also want to detect and block web-based attacks targeting the web browsers of users in Company A’s network to protect the workstations and internal networks. However, employees at Company A often use online banking services that are secured with HTTPS, and these connections should not be inspected. The administrators decide to configure TLS
Inspection to detect and block -based attacks that are encrypted inside an SSL tunnel, and use a TLS Match element to globally exclude the online banking domains from decryption and inspection.
The administrators do the following:
1. Create Client Protection Certificate Authority elements and generate a new certificate and private key. In their network environment, the administrators add the Client Protection
Certificate Authority they created to the list of trusted certificate authorities in the users’ web browsers.
2. Select the Client Protection Certificate Authority in the engine properties.
3. Create a TLS Match element that prevents decryption when certificate validation succeeds for the domain names for the online banking sites that are excluded from decryption. Because the TLS Match is applied globally, the administrators do not have to use it in any specific rules.
4. Create Access rules with the default HTTPS (with decryption) Service as the Service.
5. Use the Inspection rules from the IPS Template to look for attacks in HTTP traffic.
6. Save and install the policy.
Examples of TLS Inspection
179
180
Chapter 17 TLS Inspection
C
H A P T E R
1 8
URL F
ILTERING
URL filtering compares the URLs (uniform resource locators) that end-users attempt to open to a list of URLs, which can be defined manually or through pre-analyzed and categorized addresses. When a match is found, you can configure the system to respond in the various ways.
The following sections are included:
Overview of URL Filtering (page 182)
Configuration of URL Filtering (page 183)
Examples of URL Filtering (page 184)
181
Overview of URL Filtering
URL filtering can prevent end-users from intentionally or accidentally accessing most web sites that are objectionable (based on the content they contain) or potentially harmful (for example, phishing and malware sites). This type of content filtering can increase network security and enforce an organization’s policy on acceptable use of resources.
In URL filtering, the engines compare the URLs in web browser page requests against a list of forbidden URLs. There are two ways to define the forbidden URLs:
• You can define a small number of blacklisted URLs manually according to your own criteria.
• You can filter access according to a supplied URL categorization scheme (for example, filter out ‘adult content’).
Both methods can be used together. You can also define whitelisted URLs manually if a useful site happens to be included in a category of URLs that you otherwise want to block.
The URL categorizations are provided by the external BrightCloud service. BrightCloud provides categories for malicious sites, as well as several categories for different types of non-malicious content you may want to filter or log. Category-based filtering with BrightCloud is a licensecontrolled feature.
The categories allow you to configure policies based on the types of sites to block instead of manually typing in URLs. The individual URLs included in the categories are updated continuously. The engines query the actual URLs from the external URL categorization service to access up-to-date URL listings. The individual URLs are not viewable in the Management Client except when a match is found in traffic and the match is logged.
Different responses can be taken when a URL match is found: for example, you can log the matches or block the traffic. If you decide to block traffic, the engine can additionally notify the end-user with a custom message that the end-users see in their browsers instead of the page they tried to open.
When URL filtering is used, Strict TCP inspection is automatically applied to TCP connections.
See TCP Modes for Deep Inspection (page 60).
182
Chapter 18 URL Filtering
Configuration of URL Filtering
Illustration 18.1 Elements in the Configuration
Inspection Policy
Situations
Access Rules
Security Engine
The URL filtering feature is configured through McAfee-supplied URL Filtering Situations and/or manual URL lists. The Access rules and the Inspection Policy define how URL Filtering Situations are matched to traffic and what kind of reaction a match triggers. URL Filtering Situations can be configured to directly override other Situations to whitelist some URLs manually (as explained further in this chapter).
Since the URLs that are included in category-based filtering are defined dynamically by an external service, it is not possible for you to manually add new categories or edit the existing ones. The URL category names are updated through dynamic update packages.
Default Elements
There are default elements for the categories you can use in URL filtering. These are represented by a specific type of Situation elements, which can be found under SituationsBy
TypeURL Filtering in the element tree and in the corresponding branch of the Rules tree in the Inspection rules.
The Context for manually defining lists of URLs is HTTP URL Filter (under
ProtocolsApplication ProtocolsHTTP when selecting a Context for a Situation).
The Situations that represent URL filtering categories have a distinctive blue color so that you can easily spot them in the rules. URL lists that you create yourself carry the standard red
Situation icon.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Prepare the Engine
Category-based URL filtering requires that the engine is licensed to use the BrightCloud categorization service. You must also define DNS server addresses in the engine element so that the engines can contact the BrightCloud servers.
Task 2: Create User Response Messages
Optionally, you can define customized User Responses for URL filtering matches, such as a custom HTML page that is displayed in the end-user’s browser when a connection is blocked.
Configuration of URL Filtering
183
Task 3: Blacklist/Whitelist Individual URLs
The HTTP URL Filter Situation Context allows you to create Situations that blacklist or whitelist
URLs that you manually define. There is only one type of list for both uses. Whether a particular list is a blacklist or a whitelist depends on the action you configure for it in the Inspection Policy.
Task 4: Configure URL Filtering Rules
The Access rules and the Inspection Policy define how URL Filtering Situations are matched to traffic and what kind of reaction a match triggers.
Category-based URL filtering can be configured in the IPv4 or IPv6 Access rules, or in the
Inspection rules. In the Access rules, category-based URL filtering is configured as part of the matching criteria in the Service definition. URL filtering based on URL lists can be configured in the Inspection Policy.
Different URL filtering features require you to adjust either the main Inspection Rules tree or the
Exceptions. The URL Filtering branch in the Rules tree contains all category-based filters by default, making it easy to activate filtering for content categories and subcategories. Whitelists must be configured as Exceptions. Blacklists can be configured as parts of the Rules tree or as
Exceptions depending on your needs. User Responses are configured in Exceptions. You can use the Continue action to set User Response options for other Exceptions and the Rules tree.
See Inspection Policies (page 117) for more information on Inspection rule configuration.
The available categories may change when you activate a new dynamic update package, and be automatically enforced after the next policy upload (depending on the Rules tree settings).
Examples of URL Filtering
Allowing a Blocked URL
The company is using category-based URL filtering. Among other categories, the administrators have blocked end-users from viewing web sites categorized as “Questionable” in the Rules tree.
However, now one of the network security administrators notices that they are blocked from accessing a hacker-oriented site that they have occasionally browsed to research new security threats. To make an exception for their own use, the administrators:
1. Create a new Situation called “URL Filtering Whitelist” with the Context “HTTP URL Filter” and type in the URL of the hacker site they want to access.
2. Add the following type of new Exception Rule.
Table 18.1 New Rule for Allowing a URL Above the Previously Added Category-Based Rule
Situation
Custom “URL Filtering
Whitelist” Situation
Source
Administrator’s workstations
ANY
Destination
Permit
Action
184
Chapter 18 URL Filtering
C
H A P T E R
1 9
A
PPLICATIONS
Application elements collect together combinations of identified characteristics and detected events in traffic to dynamically identify traffic related to the use of a particular application.
The following sections are included:
Overview of Applications (page 186)
Configuration of Applications (page 186)
Examples of Applications (page 188)
185
Overview of Applications
Applications are elements that provide a way to dynamically identify traffic patterns related to the use of a particular application. Applications allow you to more flexibly identify traffic beyond specifying a network protocol and ports for TCP and UDP traffic with a Service element.
Matching is done based on the payload in the packets, making it possible to identify the protocol even when non-standard ports are used. Applications first identify the protocol, and then a protocol-specific pattern matching context is applied to identify the applications.
Configuration of Applications
No configuration is required to be able to use Applications in Access rules. There are several predefined Application elements available that define the criteria for matching commonly-used applications. Creating new Applications or duplicating existing elements is not recommended. If you need to override the settings of a predefined Application, you can edit the Service Definition of the rule in which you use the Application.
Default Elements
Application Type elements define general categories of applications. One Application Type can be associated with each Application. Application Types are predefined, and you cannot create new Application Types.
Tags help you to create simpler policies with less effort. Tag elements represent all Applications that are associated with that Tag. For example, the Media Tag includes several web-based image, music, and video applications. Several Tags can be associated with each Application.
TLS Match elements define matching criteria for the use of the TLS (transport layer security) protocol in traffic. When a connection that uses the TLS protocol is detected, the server certificate for the connection is compared to the TLS Match in the Application definition. TLS connections are allowed only to sites that have trusted certificates that meet the following criteria:
• The certificate domain name must match the domain name in the TLS Match element.
• The certificate must be signed by a valid certificate authority.
• The certificate must be valid (not expired or revoked).
The predefined elements are imported and updated from dynamic update packages. This means that the set of elements available in your SMC changes whenever you update your system with new definitions. The Release Notes of each dynamic update package list the new elements that the update introduces to your SMC.
186
Chapter 19 Applications
Configuration Workflow
The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Define TLS Matches
In addition to the predefined TLS Matches used in predefined Applications, you can optionally define your own TLS Matches.
TLS Matches can match traffic based on the following criteria:
• Whether certificate validation succeeded, failed, or was not performed.
• The server domain name in a valid certificate.
• Specific reasons a certificate is considered invalid if certificate validation failed.
TLS Matches also specify whether to decrypt TLS traffic to particular Internet domains for inspection. TLS Matches that deny decryption are applied globally. Even if the TLS Match element is not used in the properties of any Applications or in the Access rules, matching connections are never decrypted. Denying decryption in a TLS Match prevents Applications from being detected in encrypted connections to the specified domain(s). If the server certificate provides sufficient information to identify the Application without decrypting the client communications, you can alternatively specify that decryption is not necessary for application identification in the Application Properties.
An Application matches a TLS connection only if a TLS Match element in the Application also matches. However, TLS Matches used in Service Definitions override the TLS Match of an
Application. In this case, the rule matches when the TLS Matches specified in the rule match.
Task 2: Create Access Rules
To detect application use, you must create Access rules and use an Application in the Service cell. You can either use Applications directly in the Service cell, or as part of the Service
Definition. Any other criteria in the Service Definition override the Application properties. For example, the predefined Google Application matches only TCP ports 80 and 443, but using the
Any TCP Service allows the Application to match any traffic pattern that resembles the use of
Google regardless of the port.
Alternatively, you can use Application Types and Tags directly in the Service cell to match any of the Applications that belong to the Application Type or Tag group.
Some Applications can open several related connections. If a related connection is identified by an Access rule that detects Application use, the related connection is matched against the
Access rules again. If the rule that detected the Application use has Deep Inspection enabled and the related connection matches a rule that has Deep Inspection enabled, the related connection is matched against the Inspection Policy.
Configuration of Applications
187
Examples of Applications
The example in this section illustrates a common use for Applications and the general steps on how the scenario is configured.
Blocking Application Use
The administrators at Company A want to allow the use of HTTP in general, but block the use of social media applications from its corporate network. When social media use is detected, the administrators want to redirect users to the corporate security policy page on the company intranet.
The administrators:
1. Create a User Response to redirect dropped connections to the corporate security policy intranet page.
2. Add the following Access rules:
Source
Internal networks
Internal networks
Destination Service
Not internal networks expression
Social Media
Application Tag
Not internal networks expression
HTTP
3. Refresh the IPS engine’s policy.
Action
Discard
Response: User Response to redirect connections to the intranet page
Allow
188
Chapter 19 Applications
C
H A P T E R
2 0
B
LACKLISTING
Blacklisting is a way to temporarily block unwanted network traffic either manually or automatically with blacklist requests from a Security Engine or Log Server. Blacklisted connections are blocked for the duration of blacklist entries, after which the connections are again allowed.
The following sections are included:
Overview of Blacklisting (page 190)
Configuration of Blacklisting (page 191)
189
Overview of Blacklisting
Blacklisting makes it possible to block unwanted network traffic for a specified time. Engines can add entries to their own blacklists based on events in the traffic they inspect. Security
Engines and Log Servers can also send blacklist requests to other Security Engines. You can also blacklist IP addresses manually.
Risks of Blacklisting
Blacklisting can have unintended consequences that could disrupt business-critical traffic. Use blacklisting with careful consideration. The following two categories represent the typical risks associated with blacklisting:
Table 20.1 Risks of Blacklisting
Risk
Blacklisting legitimate connections (false positive)
Causing self-inflicted denialof-service (DoS)
Explanation
If the defined pattern for detecting malicious traffic is inaccurate, legitimate traffic may sometimes be blacklisted. This causes service downtime for hosts that are incorrectly identified as a source of malicious traffic.
When an attacker uses spoofed IP addresses, a different (legitimate) IP address may be blacklisted instead of the attacker’s IP address. This may cause a self-inflicted denial-of-service on legitimate traffic.
These risks can be minimized with good planning. The threats must be identified and evaluated carefully, and blacklisting must be defined only with good reasons.
Limitations of Blacklisting
• Layer 2 Firewalls can only blacklist IPv4 traffic.
• There is no direct communication between different Virtual Security Engines or between
Virtual Security Engines and the Management Server. This means that Virtual Security
Engines cannot send blacklisting requests to other Virtual Security Engines, or to Security
Engines.
190
Chapter 20 Blacklisting
Configuration of Blacklisting
Blacklisting is executed as defined in the Access rules of the Firewall Policy, the Layer 2 Firewall
Policy, or the IPS Policy. Automatic blacklisting requests are sent as defined in the Inspection
Policy.
Illustration 20.1 Blacklisting Process
Security
Engine A
Log Server
Security
Engine B
1
Blacklist
2 3
Blacklist
4
Access
Rules
Management
Server
Access
Rules
Management
Client
1. Engines add entries to their own blacklists for traffic they inspect.
• There is one blacklist for each Firewall, Layer 2 Firewall, IPS engine, or Virtual Security
Engine.
• In engine clusters, there is one blacklist for each cluster. The nodes in the cluster exchange blacklist information in their synchronization communications.
2. Log Servers send blacklisting requests as a response to correlation of detected events.
When one Security Engine sends a blacklisting request to another Security Engine, the
Log Server relays the blacklisting request to the Management Server.
3. Management Servers relay manual blacklisting commands from administrators, and blacklisting requests sent by Log Servers to the Security Engines.
4. Engines enforce the entries on their blacklists according to their Access rules.
• Each blacklist entry exists only for a defined time period after which the entry is cleared and matching connections are again allowed. The duration of the blocking is defined when the blacklist entry is created.
• Access rules check connections against the blacklist. If the IP addresses and ports in one of the blacklist entries match, the connection is discarded.
• If the connection does not match a blacklisting Access rule or its related blacklist entries, the next Access rule in the policy is checked as usual.
Configuration of Blacklisting
191
192
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC
Administrator’s Guide.
Task 1: Define Blacklisting in Access Rules
Access rules define which components are allowed to add entries to an engine’s blacklist, and which connections are checked against the blacklist. Blacklisting is applied with Access rules that contain the Apply Blacklist action. Only connections that match the blacklisting Access rules are blacklisted.
No further configuration is needed if you want to blacklist connections manually. Task 2 explains the additional configuration needed for automatic blacklisting with the Inspection Policy.
Task 2: Define Exceptions in the Inspection Policy
Blacklist scope options in the Exceptions of the Inspection Policy trigger automatic blacklisting for the detected events. You can define Blacklisting scope options for any type of Exception, including rules that use Correlation Situations. Automatic blacklist entries are created using the detected event’s IP source and destination addresses, and optionally the TCP or UDP ports. If the event does not contain this information, a blacklist entry cannot be created. Netmasks can optionally be used to blacklist the detected event’s network.
Using Blacklisting
Manual Blacklisting
You can blacklist connections manually through the Management Client. There are three ways to create new blacklist entries manually. You can blacklist a connection found in the log data, define a new blacklist entry for a Security Engine element, or create new blacklist entries in the
Blacklist view. Blacklist entries can be removed and added manually.
Monitoring Blacklisting
The currently active blacklisting entries on the engine can be monitored in the Blacklist view.
Blacklist monitoring does not show you which connections are actually dropped. Blacklist monitoring only shows you the IP addresses that are currently on the blacklist. The Logs view can show which connections are actually dropped, depending on the logging options you have set. The blacklist can be sorted and filtered in the same way as log entries.
Whitelisting
Whitelisting means defining a list of IP addresses that must never be blacklisted. Whitelisting is implemented by following general Access rule design principles. Blacklisting applies only at the position of the blacklisting Access rule(s) in the policy. Connections that have already been allowed or discarded before the blacklisting rules is not affected by blacklisting. If an Access rule in the policy allows a connection, an Access rule that refers to the blacklist further down in the policy cannot blacklist the connection.
Chapter 20 Blacklisting
advertisement
advertisement