M17 Firewall Policies

Firewall Policies ©2012 McAfee, Inc. All Rights Reserved. 1


Upon successful completion of this module you will be able to: • Define the NSP Firewall feature • Configure Firewall policies • Define Firewall Rule Objects • Add a Rule Object to a Firewall Policy • Create Firewall Policies • Describe how to find and use Firewall Logging • Compare the differences between Advanced and Classic Firewall features • Configure Firewall Policies and assign them to Sensors



Network Security Platform enables the creation of a Firewall Policy with ordered rules for permitting and denying traffic from reaching a Sensor’s inspection engine and continuing on through the network. A Sensor firewall policy is useful for maximizing a Sensor’s detection and prevention capabilities by dropping or rejecting specified traffic without requiring full inspection. Most commonly deployed in firewalls, is a set of ordered rules that governs what traffic is permitted to pass and what traffic is denied access beyond the device. The inclusion of firewall policies does not, however, make Network Security Platform a replacement for a firewall. Unlike many firewall offerings today, Network Security Platform does not, for example, support NAT, act as a VPN end point, or provide connection tracking for all protocols. Based upon firewall policy inspection, Network Security Platform can: • Drop (block TCP traffic only) • Deny (Send a TCP reset to source, destination or both) • Inspect (send traffic to the inspection engine) • Ignore – (doesn’t do IPS inspection on the packets)

Firewall policies are executed in top-down sequence: the rule at the top of the list is checked first, followed in order by subsequent rules down to the bottom most rule. Network Security Platform employs a first-match process; the first firewall policy rule matched in sequence is enforced. You can assign multiple Firewall Rule sets that cumulatively add rules to the firewall policy.


A firewall policy is useful for maximizing a sensor’s detection and prevention capabilities by denying specific traffic without requiring full inspection, while also permitting certain traffic to pass without inspection.

You can enforce policies based on various parameters. You can base it on the application, the source or destination country of the traffic, the source or destination network, the source or destination host, and so on. Customers can create their own Firewall policies or re-configure the two pre-defined Firewall policies – classic and advanced. Advanced firewall policies provide more options to filter traffic when compared to Classic. NOTE: The advanced firewall feature uses application identification. Traditionally firewalls are layer 4 based. But, with so many applications running across the internet and looking like HTTP, firewalls needs to be able to identify applications and create policies to handle them. NSP makes this possible with a separate application identification engine. Applications are identified in a hierarchical manner – TCP application, HTTP application, then finally the actual application. This hierarchy results in a parent/child relationship in firewall policy processing - meaning that for the top level application to be allowed by the firewall the underlying application must also be allowed. For application identification to take place on the firewall, the feature must be part of the firewall policy.


Network Security Platform has the following advantages over a typical firewall implementation: • The implicit Network Security Platform behavior, unless overridden by an explicit Firewall Policy

rule, is to permit the traffic and scan it for intrusions. This is in contrast to most routers, which permit all traffic by default, and most firewalls, which block all traffic by default.

• If you choose to allow traffic, you also have the option to bypass intrusion scanning. As the user interface describes it, you can choose to Inspect or Ignore, where Ignore means to permit without intrusion scanning.

Firewall Policy versus Exceptions Exceptions are used to create scanning exceptions by IP and attack signature. Exceptions are a more granular way than firewall policies to create scanning exceptions; exceptions can be applied to a single attack rule, for example. Firewall policies complement exceptions by making it very easy to exclude an entire host or group of hosts from the scanning process without having to do a bulk edit. For example, you can build an exception to ensure the host at 1.1.1.1 never triggers the SQL Slammer signatures. Firewall policies complement exceptions by making it very easy to exclude a host, group of hosts, or protocols from the entire scanning process. Moreover, exceptions are applied to alerts after the scanning process. That is, they indeed allow the matching traffic to pass and ensure alerts will not be generated, but only after the scanning process takes place. Conversely, if traffic matches an firewall rule that is configured to permit only (no IDS), the traffic bypasses the engine, which decreases overall sensor scanning overhead.


Firewall Rules Advanced Firewall polices are made up of firewall rules, which are in turn made up of rule objects. Rule objects are the characteristics used by the firewall to identify traffic, such as host address, network addresses, services, host names, and more. These rule objects support the granular handling of traffic by the firewall. Multiple rule objects can be applied to the firewall rule and in turn multiple firewall rules can make up a policy. The Firewall policy can be assigned at multiple level or points - Device -Pre Interface/Sub Interface Port Device -Post


Rule Object Types Rule objects have been grouped into Types. Explanation of types is available in the Network Security Platform documentation. If you select a type - network, then you are going to be adding a list of CIDRs to your rule object. If you select a finite time period then you would be prompted to enter a start and end date to add to your rule object. Some of the types, shown in the table, lend themselves to grouping multiple objects such as application group. If you select application group then you would be prompted to enter any number of applications or capabilities into your rule object. The same handling occurs with network group where you can combine countries, host IPs, names, etc. The use of rule objects allows for ease of reuse because a single rule object can be applied to many different policies.


Application Identification Application Identification is a new feature that allows IPS reports and firewall rules to identify traffic based on specific application. This is currently supported only on M-series sensor. Over 1100 applications and sub-applications are recognized. McAfee Labs rates the applications and application capabilities, and determines their threat level. This threat probability can be used to create firewall policies that block high risk applications. Application information can be forwarded to NTBA in netflow records. Application identification information can be used help administrators understand the high risk applications running on their network and the amount of bandwidth various types of applications are taking up. Normally network level signatures look for patterns, ports, or packet attributes. The IDT team is responsible for creating the protocol and attack specifications used for identifying layer 7 attacks. Application signatures are different. To identify an application, various blocks, or signature blocks are evaluated. Low level information such as byte patterns and packet attributes are considered first. Then phases of an application are considered. By phases, I mean components of an application – everything from application login to sub applications such as Facebook applications or chat. There is a separate application detection engine that assesses applications and tries to identify them. Applications are identified in a hierarchical manner, for example the application may be first recognized as a TCP application, then an HTTP application, and finally the real application – if the necessary signatures exist to make the identification.


Application Identification on IPS Interfaces for alerts and reports is DISABLED by default. Customers will need to configure the Sensor to make ports “application aware” for alert categorization. This has a minimal impact on performance as the sensor is already inspecting traffic for alerts. Even if Application Identification is disabled, the firewall rules will still be able to block and allow traffic based on application.


Firewall polices can be applied at the sensor level and can be customized further at the interface and sub-interface levels by adding additional rules. All firewall rules are cumulative, the Pre-Device rule set (Sensor level) is checked first, followed by the Interface level, then Port level and then on to the Post-Device rule sets. If wanting to apply a firewall rule across all of a device’s interfaces, configure it at the Pre-Device level and it will automatically block any traffic before allowing it down to the interface level.


One easy way to see if the firewall rules are being triggered is to use the syslog notification system. Use the rule match notification feature. You can enable syslog notification in the event that one of the firewall rules is matched on the firewall. Under Manage page Setup Notification Firewall Access Events Syslog you can enter syslog configuration information and test the connection. Firewall logging requires significant resources on both the Manager and Sensors. To eliminate some of the overhead on the Manager, a design decision was made to forward firewall policy events off-box using syslog instead of storing them locally. Sensors forward firewall policy events to the Manager the same way they do normal alerts. The Manager then reformats them and forwards them to a remote syslog server for processing and storage. Even with Firewall log suppression in use, logging can potentially generate enough traffic between the sensors and Manager to cause normal alerts to be dropped. For this reason, we recommend that firewall logging only be enabled as required for troubleshooting.


Next, make sure that firewall logging is enabled on the sensor, and that it is configured to forward traffic that matches a rule to the syslog server.


We’re going to go through and example firewall policy. For our example we are going to block traffic to and from QQ.com – a large Chinese web portal.


Create a Rule Object We’ll first create a rule object to define the site. Shown here are the beginning steps for creating a new rule object. Under Rule Objects, we see an entire list of rule objects already available. You also have the ability to search rule objects. In the example, searching for “qq” produces a list of already existing rule objects for QQ related objects (games, mail, music, etc.). In our example, we will create a group for these QQ objects.


We know we want to block an application, and not on a custom port, so we need to choose Application Group. Then you can search for the name of all the available applications to add to the application group. In this example, typing “qq” results in a list of all available QQ related applications.


You can arrow over available applications into the Application Group. Remember you can also do this for: • CIDR Networks, IPv4 address ranges and countries (Network Groups) • Services like TCP/UDP Ports, ICMP, Other Protocols (Service Groups)


Now we need to create a firewall policy to block QQ. First, create a new firewall policy and name it. This will be an Advanced policy as opposed to the former functionality which is now under the classic type. If you later edit this rule from the Firewall Policies screen you will see statistics about the Rule including: • When it was updated • Who it was updated by • Where it is assigned • Where it is assigned as an inbound or outbound rule.


When we get to the Access Rules page we can add our new rules. You can highlight an access (firewall) rule and then either insert a new rule above or below. You can move the rules up or down, clone a rule and delete a rule. You can enable or disable the access rules from here by changing the value in the enabled field. You can also click on the various columns and configure or modify, making the firewall policy as specific or as generic as you want. The columns that show up depend upon whether you selected classic or advanced policy. For this example, we will keep the source and destination as Any, though you could choose an IP, a host name, a country, or groups of network objects. What we will change is the application.


When you edit the application field, the rule objects list appears. This allows you to search and find specific objects or you can use the scroll bar. We created an object named “QQ Applications”, so we will select it.


Next we will modify the response so that any QQ traffic gets dropped. This brings up the response dialog box, allowing you to select any number of primary actions, inspect, drop, deny or ignore. Primary Action: • Scan – Pass traffic and inspect for intrusions • Drop – Silently discard traffic • Deny – Discard traffic and send a Reset (if applicable) • Ignore – Pass the traffic without inspection • Stateless Ignore – Pass the matched packets without inspection • Stateless Drop – Silently discard matched packets • Require Authentication – Require all traffic over HTTP to be authenticated


After creating the policy (remember you can use multiple rules) you can assign the policy to a device (pre and post), port pair, interface and sub-interface. Remember these policy assignments are cumulative so it doesn’t make much sense to assign the same policy to the device, interface and sub-interface. Only target the rule to the traffic you want it to apply to.


Once a Firewall policy is assigned you can click on the number under Assignments to see where the policy is applied and also change any assignments the policy has. You cannot delete a firewall policy that is assigned to a resource. Remember you can also go under the Protection profile of the Sensor, Interface and Sub-Interface and directly apply a firewall policy using the dropdown menu, or create a new one.


Notice here the policy assigned to MU-1450 2A-2BNetworkC-HR has 4 rules. The administrator defined the same policy for the Pre and Post sensor firewall policy. This is an ordered list so Rule #3 will never be checked as ping traffic will always be blocked by rule #1. Rule #4 is the default Firewall policy rule that is a “catch all”. Any traffic not matching a firewall policy will be permitted through the sensor and inspected. General rules for building firewall rules: 1. Deny rules before permit rules 2. More generic (larger IP area) rules before specific rules 3. Apply policy to the smallest possible interface (apply to the Sub-Interface if that is where the

traffic you need to block is, not the entire sensor)


Shown here are the steps in creating an example Classic firewall policy.


In Classic Firewall Policies you don’t have the ability to restrict traffic via application type or time.


You can still group assign multiple Services, Sources and Destinations to a classic firewall policy, but you will be unable to create groups.


In a classic firewall policy, you can still choose between Scan, Drop, Deny and Ignore.


You will need to deploy the configuration changes to the Sensor in order for the new policy to be enforced.


Shown here are the Sensor firewall policy limits. Example: Computing firewall rules utilized per sensor On an M-3050 sensor, for example, if you configure 8 rules at the sensor level, 20 rules on port pair 2A-2B, and 10 rules on the sub-interface of 4A-4B, you would have utilized 38 out of the 3000 limit. You can also calculate the number of firewall rules utilized by adding the number of firewall rules displayed at the sensor level, each port level, and each sub-interface level. Computing Number of firewall rules utilized during port clustering When port clustering (interface grouping) is used, and port-level firewall rules are configured, the number of firewall rules utilized (for each port-cluster-level) will be different based on the participant port-types of the cluster. One firewall rule will be consumed per each inline port-pair member, and one firewall rule will be consumed per each SPAN port member of the port cluster. Examples: Computing the effective firewall rule utilization for each port-level rule defined for a port-cluster • Port cluster 1–If your port cluster consists of 1A-1B (inline, fail-open), 2B (SPAN), and 4A-4B

(inline, fail-close), 3 firewall rules will be consumed for each firewall rule configured at the port level.

• Port cluster 2–If your port cluster consists of 1A (SPAN), 4A (SPAN), 5A (SPAN), 6A-6B (inline, fail-close), 4 firewall rules will be consumed for each firewall rule configured at the port level.


Customers can export pre-defined, selected Firewall Policies to the local file system as XML documents. They can also select firewall policies and then import them into the NSP Manager for application to available resources.



Documents

M17 Firewall Policies