NAT rules must usually be adjusted for content inspection server redirection. The Protocol Agent handles the translation of addresses when forwarding the traffic from the firewall to the content inspection server and there must not be overlapping address translation defined for these connections in the NAT rules. A matching rule with an empty NAT cell may be needed to ensure other NAT rules do not match to these connections.
Any NAT you want applied to proxy connections opened by the content inspection server must be done using normal NAT rules.
Using Content Inspection
The main benefit in redirecting traffic to a separate content inspection server is that it works transparently: the communicating hosts need no additional proxy configuration when CIS redirection is used. However, the redirection uses NAT, which may sometimes cause problems if you want the CIS to treat traffic differently based on IP address. In such cases, it may be necessary to configure the CIS server traditionally on the clients instead of using the Firewall’s redirection feature.
To illustrate how the connections are handled, the following table shows an example of the source and destination IP addresses that are used in redirected connections at different stages.
This example may be useful when planning the Access rules. The client’s translated IP address in the redirection must be different from the public translated IP address normally used for the client’s Internet connections. There are two different connections: one connection between the client and the content inspection server, and a second connection between the content inspection server and the server that is the target of the client’s connection.
Table 18.1 Addresses Used in Content Inspection Server Redirection
Communication Source IP Address Destination IP Address Client to firewall Client’s private IP address Target server’s public IP address Firewall to CIS Client’s translated IP address Content inspection server’s private IP
address CIS to firewall Content inspection server’s private IP
address Target server’s public IP address
Firewall to server Content inspection server’s public IP
address Target server’s public IP address
Server to firewall Target server’s public IP address Content inspection server’s public IP address
Firewall to CIS Target server’s public IP address Content inspection server’s private IP address
Content inspection server’s private IP
180 Chapter 18 External Content Inspection
This scenario requires two Access rules (one for each connection) and one NAT rule (for the connection between the content inspection server and the target server). To see how these types of communications are reflected in firewall Access and NAT rules, see Example of Content Inspection (page 180).
Alternatively, anti-virus features (separately licensed feature) are available directly on the Firewall for low-traffic environments. See Virus Scanning (page 171) for more information. Also, limited URL filtering is available as part of the deep packet inspection features (hardware permitting).
Example of Content Inspection
The example in this section illustrates a common use for content inspection and general steps on how the scenario is configured.
Inspecting Internal User’s Web Browsing and File Transfers
The example company has decided to screen out non-work-related connections using an external content inspection server that can screen the HTTP and FTP connections that the company’s employees open to the Internet. The content inspection server acts as a proxy for these connections. The administrators have already installed the content inspection server and configured it to process HTTP and FTP traffic according to the company’s policy. To configure the redirection, the administrators:
1. Create an element for their content inspection server.
2. Create a custom Service element for both HTTP and FTP that refer to the Protocol Agents for those protocols.
3. Add the content inspection server to the Protocol Agent parameters in the Service properties.
4. Create the Access rules for redirecting connections to the content inspection server and the connections that the proxy server then opens to the Internet or any other destination.
•The table above shows rules for redirecting outgoing HTTP and FTP traffic through a content inspection server. Connections opened from the corporate LAN are redirected to the content inspection server in rule 14.1 and 14.3. The content inspection server then connects to the actual destination, which is allowed in the rules 14.2 and 14.4.
•The FTP Service without redirection in rule 14.4 also uses a Protocol Agent, as this is required for the FTP connections to be correctly handled by the firewall. However, this is the default element that is not configured for content inspection server redirection.
ID Source Destination Service Action
14.1 Internal Network element ANY HTTP-CIS-Redirect Allow
14.2 CIS Server element ANY HTTP Allow
14.3 Internal Network element ANY FTP-CIS-Redirect Allow
14.4 CIS Server element ANY FTP Allow
5. Create the NAT rules for ensuring that NAT rules do not match to connections that are being redirected to the content inspection server and rules for translating the connections opened by the content inspection server for load-balancing the connections across the company’s Multi-Link network connections.
•Rules 4.1 and 4.3 ensure that there is no address translation for the traffic that is redirected to the content inspection server (NAT cell is empty, which means no NAT is done for matching connections).
•Rules 4.2 and 4.4 are used to NAT the forward connections from the content inspection server to the actual destination, in this case, dynamic source NAT for load-balancing the traffic across available ISP links (using the Outbound Multi-Link element, which in the example company has been given the name “HQ Multi-Link”).
ID Source Destination Service NAT
4.1 Internal Network element ANY HTTP-CIS-Redirect
4.2 CIS Server element ANY HTTP Dynamic Load
Balancing: HQ Multi-Link
4.3 Internal Network element ANY FTP-CIS-Redirect
4.4 CIS Server element ANY FTP Dynamic Load
Balancing: HQ Multi-Link
182 Chapter 18 External Content Inspection
C H A P T E R 1 9
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 to Situations (page 184)
Configuration of Situations (page 184)
Using Situations (page 189)
Example of Custom Situations (page 189)
184 Chapter 19 Situations
Overview to 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 19.1 A Situation and the Associated Elements
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.
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.
Correlation Contexts
Correlation Contexts define the patterns for matching groups of related events in traffic. There are five types of Correlation Contexts:
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.
Table 19.1 Correlation Context Types Correlation
Context Type Description
Compress
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.
Count
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.
Group
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.
186 Chapter 19 Situations
Detailed descriptions of the parameters for each of the Correlation Contexts can be found in Situation Context Parameters (page 341).
Anti-Virus Contexts
The Anti-Virus Contexts are used to detect viruses in HTTP, HTTPS, IMAP, POP3, and SMTP protocol traffic. You must have a license that supports Anti-virus inspection to be able to use these Contexts for traffic inspection. Anti-virus inspection is not supported on Master Engines or Virtual Security Engines.
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 web sites.
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.
Sequence
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.
Table 19.1 Correlation Context Types (Continued) Correlation
Context Type Description
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.
System Contexts
The System Contexts are used for errors and other system events. They are internal to the McAfee Security Management Center (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 available 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.
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 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 128) 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.
188 Chapter 19 Situations
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.
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 345).
The Correlation Situation parameters are explained in Situation Context Parameters (page 341).
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.