Firewall Access Policy Rulesets, Part 1
Firewall Access Policy Rulesets, Part 1
This article continues the series of articles on Firewall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced on this site earlier with articles Getting Started With Firewall Builder, Using Built-In Revision Control In Firewall Builder, Using Built-in Policy Installer in Firewall Builder, Using Firewall Object In Firewall Builder.
This article explains key principles of the policy or access control rule sets in Firewall Builder. I plan to demonstrate examples of policy rules and how they translate into iptables, pf and Cisco IOS and PIX configurations in the next article of the series.
More information on Firewall Builder, pre-built binary packages and source code, documentation can be found on the project web site at http://www.fwbuilder.org/. Numerous examples of iptables, pf and other rules are available in Firewall Builder Users Guide. Follow Firewall Builder Project Blog for announcements and articles on all aspects of using Firewall Builder.
One of the fundamental principles on which Firewall Builder is based is that it does not aim at just supporting one particular firewall platform. The goal is to be able to generate configuration for many different firewalls from the same representation in the GUI. To do this, Firewall Builder works with an abstract high level model of a firewall which incorporates features found in all target firewalls. In other words, Firewall Builder is not another iptables GUI, or PF GUI, or PIX GUI. Firewall Builder works with a firewall that is neither one of these, and yet at the same time it is all of them combined. It has useful features found in all of the target platforms. If a feature that it implements is not supported in some target firewall, it tries to emulate it (if possible) to make it look like the target really supports it.
Target firewalls sometimes differ in very fundamental principles of operation. This can make managing policies in the multi-vendor environment challenging because administrators have to break their habits while switching from one platform to another and back. This inevitably leads to human errors in the configurations they write and as a consequence, network outages. For example, most of the platforms supported by fwbuilder process rules top-down, with the first matching rule making decision and stopping processing. However PF by default does it in the opposite way, with each matching rule not stopping processing and the last one making final decision. There is no "right" way of doing this and both approaches will do the right thing, provided configuration is written with understanding of how the firewall works. However, if an administrator is used to some method, it is hard to switch back and forth while managing different firewalls. Another example of similar discrepancy is the order in which access control and nat rules work on a packet. Most firewalls supported by fwbuilder do nat first, so that access control rules "see" translated addresses in the packet. PIX, on the other hand, does it in the opposite order, with access control rules working on the packet before nat. This means access lists on PIX should be written in a different manner than, say, iptables rules for Linux or pf rules for OpenBSD firewalls.
Since Firewall Builder works with an abstract firewall, all these discrepancies go away and administrator always sees consistent model regardless of the chosen target firewall platform. For PIX, the program can make it look like NAT is done after access control rules (but this is optional). For PF, the program always uses PF option that switches it to the non-default "first match" behavior. In the end, the program takes care of translating the firewall model it presents to the user into configuration of the actual target firewall.
That said, policy rules described in this article will look very familiar to anyone who ever worked with Firewall-1, PIX, iptables, PF and so on. These rules are just generalization of the ideas and features found in all of those firewalls. The GUI helps administrator create and manage rule sets and policy compilers then translate them into configuration language of the chosen target firewall platform.
The main Firewall access policy consists of a set of rules. Packets are analysed by comparing their parameters with rules in the policy, one after the other, from top to bottom. The first rule that matches the packet has it's Action applied to the packet.
Each rule includes a standard set of parameters, or Rule Elements, that are used for comparison with the packet. Rule elements include "Source", "Destination", "Service", "Interface", "Direction", and "Time". For example, if a packet entering the firewall has a source address that matches the object in the Source field of the rule, its destination address matches the object in Destination, its protocol and port numbers match the object in Service, the interface it passes through matches the Interface field, its direction matches that specified in Direction, and it's time matches Time, then the firewall will take action, specified in the Action field of the matching rule. Of course, a field with "Any" or "All" in it will match all packets for that field.
For example in the screenshot above, rule #0 is "anti-spoofing", it denies all packets coming throuh the outside interface with source address claiming to be that of the firewall itself or internal network it protects. This rule utilizes interface and direction matching in addition to the source address. rule #2 says that connection from the internal network (object net-192.168.1.0) to the firewall itself (object firewall) using ssh is allowed (action Accept). The "Catch all" rule #6 denies all packets that have not been matched by any rule above it. The access policy in the screenshot is built to allow only specific services and deny everything else, which is a good practice.
Access Policy rules represent access control because they define which packets will be permitted and which will be denied. Access Policy rules operate on the packet's source and destination addresses and protocol parameters. These rules work regardless of the interface and direction of the packet, unless a particular interface or direction, or set of interfaces, is assigned to the rule.
Source and Destination
The Source and Destination fields allow you to match a packet to a rule based on source and destination IP address.
Either field may be set to "any", which means that the packet will match on that field regardless. Or, you can set a field to a particular IPv4 address (Address object), IPv6 address (Address IPv6 object), the IP address or addresses associated with all interfaces of a host (Host object), a range of IP addresses (Address Range object), all the addresses in a particular subnet (Network object), an address configured as DNS "A" record for a given host name (DNS Name object), or a group of any of the above. You can place more than one object in either field, too. These object types have been covered in the articles published on this site here, here, here, here, here and here. You can find detailed description of all object types and their usage in policy and NAT rules in the Firewall Builder Users Guide which you can download from our web site at http://www.fwbuilder.org. We have both PDF and HTML versions.
In addition, you can "negate" an object by dragging it to a field, then selecting Negate from the right-click menu. In the following screenshot, the RFC 1918 address range object has been negated, so the rule matches any destination address that is not part of private address space.
Destination matches any IP that is not an RFC 1918 address
The Service field is also used to match packets to rules. Use Service Objects to specify what services should be matched. The service object types have been discussed in the series of articles on this site: IP Service, TCP or UDP Service, ICMP or ICMP6 Service and Custom Service.
As in the Source and Destination fields, you can "negate" an object by dragging it to a field, then selecting Negate from the right-click menu.
By default, all rules created in Firewall Builder affect all firewall interfaces, regardless of the target platform. However, sometimes you want to assign a rule only to a particular interface or set of interfaces. To populate this field, drag an interface object from the firewall object the rule set belongs to.
If you also want to assign a "direction" to the rule, use the next field.
This field applies to firewall interfaces only, not host interfaces.
The "direction" for a rule is defined with respect to the firewall machine, not to the network behind it. For example, packets that leave the internal network through the firewall are considered "inbound" on firewall's internal interface and "outbound" on its external interface. Likewise, packets that come from the Internet are "inbound" on the firewall's external interface and "outbound" on its internal interface. The following diagram illustrates directions for packets entering or exiting the firewall interface:
The Action is the action taken on a rule that matches on the Source, Destination, Service, Interface, Direction, and Time fields.
The policy rule action can be one of the options listed below. Not all firewalls support all options, but the GUI will only allow options that are valid for the indicated firewall target. In addition, the same action may have a different name on different platforms.
Some actions can have parameters. To set a parameter for an action, first select the action, then double-click on the icon. (You can also right-click and select parameters.) The parameters dialog appears:
The Time field allows you to restrict a match to a particular time interval. Currently only iptables target firewall platform supports time restrictions as part of the policy rules.
The Options field allows you to specify certain options with regard to packets that match the rule. Almost all platforms have options related to logging, and some platforms have more extensive options. Click Help in the Options dialog for platform-specific help.
If the options of a particular rule have been changed from their default, an icon appears in the Option field for that rule. Keep in mind that not all rules have the same default options. For example, by default a Deny rule is stateless, because there is no reason to keep state on a connection that won't be allowed and there will be no reply or other packets to match the state. So, if you turn on state for a Deny rule, you'll see the icon.
An Accept rule has the opposite behaviour. By default, state is kept for Accept rules, so no icon appears when state is on. If you turn state keeping off, in other words, if you change the behaviour for that rule to make it different from the default, then the icon is displayed.
Working with multiple policy rule sets
Every Firewall object created in Firewall Builder has a single Policy rule set to start. For many firewalls, this is all you need. However, with Firewall Builder, you can create multiple access policy rule sets, and, if you platform supports it, branch between them. This can help you modularize your policy.
Here we have Firewall object "fw" with three policy rule sets, Policy, Policy_2 and mgmt:
To create an additional rule set, right-click on the Firewall object in the tree and select Add Policy Rule Set.
All Policy rule sets have configurable parameters. To see a Policy rule set's parameters, double-click on it in the tree to open it in the editor.
This dialog has a Name, IPv4/IPv6 setting and a Top ruleset checkbox. For iptables firewalls, there is also a pair of radio buttons that indicates whether the policy should affect filter+mangle tables or just mangle table.
The IPv4/IPv6 pull-down menu lets you select whether the rule set should be compiled for IPv4 only (ignoring any IPv6-related rules), IPv6 only (ignoring any IPv4-related rules), or for both IPv4 and IPv6. If both IPv4 and IPv6 are selected, the compiler "does the right thing" and puts each rule into the correct part of the configuration.
Only one rule set can be tagged as the "top" rule set. The "top" rule set is the primary rule set that is assigned to the device. Only one rule set of each type, can be marked as "top". The "top" rule set is always used (if it has any rules). Other rule sets are only used if they are the targets of branching. (In Firewall Builder 3.X, only the Policy rule set can branch.)
You can fork processing between rule sets with the "Branch/Chain/Anchor" (depending on platform) Action in a rule. In the next screenshot, the rule causes packets headed for the "fw-mgmt" host to be passed to the "mgmt" rule set.
A packet directed to the "mgmt" rule set leaves the main rule set and begins matching against rules in the "mgmt" rule set. If it matches in the "mgmt" rule set, then that action is taken. If it does not match in the "mgmt" rule set, then processing is passed back to the calling rule set.
Next article will present several examples of policy rules and demonstrate generated iptables, pf and Cisco configurations.