Changes to the routing or antispoofing configuration are only transferred to the engine when you refresh the Firewall Policy. When you change the routing or antispoofing for a Master Engine, you must refresh the policy on the Master Engine. When you change the routing or antispoofing for a Virtual Firewall, you must refresh the policy on the Virtual Firewall.
78 Chapter 8 Routing and Antispoofing
Using Routing and Antispoofing
Policy Routing
With policy routing you can route traffic through a selected gateway. These policy routing entries override other routing configuration defined in the Routing view.
A policy routing entry includes a source IP address, a destination IP address, netmasks or prefixes for the source and destination addresses, and the IP address of the selected gateway.
Only IPv4 addresses are supported in policy routing.
Antispoofing configuration may need to be changed accordingly when using manual policy routing entries.
Multicast Routing
IP multicasting is the transmission of an IP datagram to all hosts in a multicast host group, which is identified by a single destination IP address. See Multicasting (page 377) for more information. You can configure static multicast and IGMP-based multicast forwarding of IPv4 traffic. You can also configure dynamic multicast routing using the Quagga Routing Suite on the engine command line. See NGFW Engine Commands (page 319) for more information.
Static multicast does not rely on IGMP (Internet Group Management Protocol) messaging.
Because of the static nature of the configuration, static multicast is suitable for enduring configurations, such as mutually agreed multicast traffic between organizations.
In IGMP-based multicast forwarding (IGMP proxying), the firewall maintains a list of subscriptions to the multicast host group and forwards multicast traffic to the subscribed hosts. The firewall periodically queries the downstream networks for hosts that want to join the multicast host group. The firewall also processes unsolicited IGMP join/leave requests received from
downstream networks. As multicast traffic is only sent to the currently subscribed hosts, IGMP-based multicast forwarding can save bandwidth and provide faster service. IGMP-IGMP-based multicast forwarding is only supported in tree topology networks. See RFC 4605 for more information.
If you use Multi-Link together with IGMP-based multicast forwarding, make sure that you do not create routing loops. If you add a NetLink to an engine’s upstream interface, do not add a NetLink to any of the engine’s downstream interfaces.
Modifying Antispoofing
In rare cases you may need to modify the default antispoofing definitions to make exceptions to the antispoofing rules (for example, if you have defined policy routing manually). You can also disable antispoofing for an interface, if necessary.
Monitoring Routing
You can monitor the currently active routing configuration of an engine in the Routing Monitoring view. The routing configuration can be viewed as a table or diagram. You can also save versions of the routing configurations as snapshots in the Routing Monitoring view.
Examples of Routing
The examples in this section illustrate some common uses of routing and general steps on how each scenario is configured.
Routing Traffic with Two Interfaces
Company A needs to route traffic to the Internet as well as to the internal Network B, which is not directly connected to the company’s Branch Office Firewall. The company’s administrators decide to create a separate route to the internal Network B and a default route for traffic to the Internet. The administrators:
1. Open the Routing view for the Branch Office Firewall.
2. Add a Router and Network B under Interface 0.
3. Add a Router and the default element “Any network” under Interface 1.
4. Refresh the Firewall Policy on the Branch Office Firewall.
Routing Internet Traffic with Multi-Link
Company B wants to ensure high availability of Internet connections through the company’s firewall. The company’s administrators decide to use Multi-Link routing with two NetLinks to balance Internet connections. They:
1. Create two NetLinks.
2. Combine the NetLinks into an Outbound Multi-Link element to balance the connections.
3. Add one of the NetLinks under Interface 1 and the other NetLink under Interface 2 in the Routing view.
4. Add the default route “Any network” under the NetLinks.
5. Add a NAT rule to the Firewall Policy to balance the connections between the NetLinks.
6. Refresh the Firewall Policy.
80 Chapter 8 Routing and Antispoofing
Routing Traffic to Networks That Use Same Address Space
Company C’s network is connected to two partners: Network A and Network B. The Network A and the Network B partners use the same address space in their internal networks.
Illustration 8.5 Policy Routing in Company C
There are two hosts in Company C’s network. Host 1 works only with the Network A partner and Host 2 only with the Network B partner. The administrators at Company C decide to use policy routing to route the traffic between Company C’s network and the two partner sites. The administrators:
1. Create policy routing entries for Host 1 and Host 2 on the Firewall HQ Cluster as shown in Illustration 8.6.
Illustration 8.6 Policy Routing Entries for Host 1 and Host 2
2. Modify the antispoofing rules so that they take into account the routing defined with the policy routing entries.
3. Refresh the Firewall Policy on the Firewall HQ Cluster.
Firewall Cluster Host 2
10.0.0.102 Host 1
10.0.0.101
Router A
Router B
Network A
192.168.1.0/24
Network B
192.168.1.0/24
A CCESS C ONTROL
P OLICIES
In this section:
Firewall Policies - 83 Access Rules - 101 Inspection Policies - 119 Network Address Translation (NAT) - 131 Protocol Agents - 145 TLS Inspection - 155 URL Filtering - 163 Spam Filtering - 167 Virus Scanning - 171 External Content Inspection - 175 Situations - 183 Applications - 191
82
C H A P T E R 9
F IREWALL P OLICIES
Policy elements are containers for the lists of rules that determine how the Firewall, Master Engine, or Virtual Firewall examines traffic. The policy elements include Firewall Template Policies, Firewall Policies, Firewall Sub-Policies, and Inspection Policies.
The following sections are included:
Overview to Firewall Policies (page 84)
Configuration of Policy Elements (page 87)
Using Policy Elements and Rules (page 94)
Examples of Policy Element Use (page 98)
84 Chapter 9 Firewall Policies
Overview to Firewall Policies
The policy elements store rules according to which the engine examines the traffic. This chapter introduces how these elements are used by Firewall engines, Master Engines, and Virtual Firewalls. It also explains how to 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 separate chapters. See Access Rules (page 101), Inspection Policies (page 119), and Network Address Translation (NAT) (page 131).
Policy Hierarchy
The policy structure is a hierarchy 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 firewall.
•Make policies easier to read.
The template and policy hierarchy is flattened when the Firewall Policy is transferred to the engine, so the policy looks the same to the engine regardless of how it is organized on the Management Server (as long as the rules themselves are in the same order). You can also create sections of conditional 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 very simple and you do not need the benefits outlined above, you can create a very simple policy hierarchy. You can, for example, start with one Firewall Policy built on the provided Firewall Template. The same Firewall Policy can be used on more than one engine.
How the Engine Examines Traffic
A Firewall, Master Engine, or Virtual Firewall passes through only traffic that is specifically allowed in the Firewall Policy. All other traffic is discarded. All connections are handled in exactly the same way, even connections that the engine itself opens, and the management connections that the engine is intended to receive.
On Firewall Clusters and clustered Master Engines, the load-balancing filter first determines which node in the cluster actually processes the received packet. The processing then begins on the selected node.
Some clearly broken packets are dropped before any rule processing; the engine drops packets that contain no data, and ICMP error messages that are missing key information about the broken packet. You must activate diagnostic logging for packet filtering to log these invalid packets.
Note – There is no separate type of policy for Master Engines and Virtual Firewalls. Master Engines and Virtual Firewalls use the same policies as Firewalls (Firewall Policies and Inspection Policies).
The engine checks a new connection against the policy rule by rule. The header on each packet arriving on an interface is examined for the source and destination IP address, and protocol-related information, such as the port. The authentication status of the user attempting a connection and the current date and time may also be included as parameters in the examination process.
The basic packet handling process is described in Illustration 9.1.
Illustration 9.1 Connection/Packet Handling Process
1. The engine checks that the traffic is coming in through the correct interface as defined in the Routing and Antispoofing trees.
1.
2.
3.
4.
5.
6.
7.
86 Chapter 9 Firewall Policies
3. If the packet is not part of an existing connection, the packet is compared with the Access rules in the installed Firewall Policy. The processing continues until the packet matches a rule that tells the engine to allow or stop the packet.
•If there is no rule match anywhere else in the policy, the packet is discarded when the engine reaches the end of the Firewall Policy.
4. If the packet is allowed as an existing connection or in an Access rule, the engine checks that the packet is valid for the state of the connection. If not, the packet is dropped.
•For example, a TCP connection must always begin with a SYN packet (as defined in the protocol standards), so the engine checks that the first packet of a new connection is a valid SYN packet.
5. The engine applies Inspection rules to connections that are selected for deep packet inspection in the Access rules.
•Inspection applies to all packets in a connection, so the Inspection rules are applied even if the packet is a part of an existing connection.
•The Inspection rules are used to look for harmful patterns hiding in the legitimate-looking connections (that is, payload of packets that are a part of allowed connections).
6. Network Address Translation (NAT) rules are applied to IPv4 and IPv6 connections. The source and destination addresses are translated according to the first matching NAT rule (or not done at all, if a NAT rule so defines). If none of the NAT rules match, the packet continues with the original addresses.
7. A routing decision is made (using the translated address). If the destination of the packet is changed by a NAT operation, the packet is checked against the Access rules again. If the packet is still allowed by an Access rule, the packet is let through the engine according to its priority and any bandwidth limits or guarantees that may have been defined. If the packet no longer matches an Access rule, the packet is dropped.
Configuration of Policy Elements
Four kinds of policy elements are used in the policy configuration for Firewalls, Master Engines, and Virtual Firewalls:
•A Firewall Template Policy is a policy that is used as the basis for Firewall Policy and other Firewall Template Policy elements. A Template Policy may contain any number of rules. The rules in the Template Policy are copied as inherited rules into the Firewall Policy or the Template Policy which is 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 Firewall Policy and Firewall Template Policy elements. You can use the same Inspection Policy with multiple Firewall Policy and Template Policy elements.
•A Firewall Sub-Policy element is a section of rules that you can insert into Firewall Policy or Template Policy elements. 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 Firewall Policy element gathers together all the rules from the different policy elements (the rules added directly to the Firewall Policy, the rules from the Template Policy used as the basis of the policy, the Inspection rules from the Inspection Policy referenced from the policy’s Inspection tab, and possibly conditional rules from one or more Sub-Policies added to the policy). A Firewall Policy is always based on a Firewall Template Policy element. The Firewall Policies are the only policy elements that can be installed on Firewalls, Master Engines, and Virtual Firewalls.
The hierarchy of how rules are inherited between the main policy elements is shown in the illustration below.
Illustration 9.2 Rule Inheritance (without Inspection Rules Inherited from Inspection Policies)
In the illustration above, 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 a 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.
Rules:
88 Chapter 9 Firewall Policies
In addition to the inherited rules, the example policy also contains any rules that the administrators add to it directly. In the policy, the administrators can only edit the rules that were added directly to the policy. To change rules inherited from Template Policy A, Template Policy B, or the Sub-Policy, they must edit the policy 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 that template.
The next time the policies based on Template Policy A are installed on the engines, the new rule is used on all of those engines. There is no need to modify each individual policy separately.
•Restrict the editing rights of administrators. For example, administrators who are granted rights to only policies cannot edit the rules defined in the Template Policies on which the policies are based. 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 it easier to read policies, and reduces 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 better throughput if the processor load is constantly very high.
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 Firewalls, Master Engines, and Virtual Firewalls.
Table 9.1 Default Policy Elements for Firewalls, Master Engines, and Virtual Firewalls
Element
A Template Policy that contains the predefined Access rules necessary for the engine to communicate with the SMC and some external components. The predefined Access rules are explained in Configuration of Access Rules (page 103).
The Firewall Template uses the Inspection rules defined in the No Inspection Policy. The Firewall Template provides access control without deep inspection.
Firewall Inspection Template
A Template Policy that is based on the Firewall Template. It uses Inspection rules defined in the High-Security Inspection Policy. The Firewall Inspection Template enables deep inspection for all traffic.
Firewall
Sub-Policy DHCP Relay
A Sub-Policy that contains rules that allow the engine to relay DHCP requests from a host in one internal network to a DHCP server in a different network, as well as DHCP requests from VPN clients to an internal DHCP server.
An Inspection Policy with a set of Inspection rules that do not enforce inspection.
Medium- 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 Firewall deployments. It is also suitable for inline IPS deployments in asymmetrically-routed networks and IPS deployments in IDS mode. The risk of false positives is low in production use.
90 Chapter 9 Firewall Policies
Situations are the central elements in 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.
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.
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.
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 Firewall deployments in which extended inspection coverage and strong evasion protection is required. The risk of false positives is moderate in production use.
The High-Security Inspection Policy is suitable as the initial policy in most environments. The High-Security Inspection Policy terminates a
The High-Security Inspection Policy is suitable as the initial policy in most environments. The High-Security Inspection Policy terminates a