Using The Interface Object In Firewall Builder
Using The Interface Object In Firewall Builder
This article continues the series of articles on Fireall 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 demonstrates how you can work with Interface objects in Firewall Builder.
More information on Firewall Builder, pre-built binary packages and source code, documentation and Firewall Builder Cookbook can be found on the project web site at www.fwbuilder.org. Watch Project Blog for announcements and articles on all aspects of using Firewall Builder.
Interface objects belong to firewall or host objects. Interface objects cannot exist alone.
The dialog for the interface object that belongs to the firewall or host provides controls for the parameters described here.
More about Security Levels and Network Zones
Consider the network layout shown in the following screenshot.
Here the firewall has three interfaces: ’outside’, ’dmz’, and ’inside’. Behind the firewall there is a router which in turn is connected to three subnets ’subnet A’, ’subnet B’, and ’subnet C’. Subnet A is shared between the router and the firewall (each device has an interface on this subnet). Let’s also suppose that we have created Network Objects for each subnet and called them ’subnet DMZ’, ’subnet A’, ’subnet B’ and ’subnet C’ (remember, spaces are allowed in object names). For this setup, network zones should be configured as follows:
Since the network zone for the ’inside’ interface consists of multiple objects, a group must be created so that you could use this group as a Network Zone object.
The following explains the differences in the way firewall platforms interpret values in the Security Level and Network Zone parameters of the firewall interfaces.
Note that "external" interface option may be deprecated in the future versions of the program
In PIX, access lists must always be attached to interfaces. Policy compiler for PIX uses information about network zones of interfaces to decide which interface a rule should be associated with if its "interface" column does not specify one (is left set to "All"). Instead of placing this rule in access lists attached to all interfaces, it compares addresses in "source" and "destination" of the rule with network zones of interfaces and uses only interfaces that match. This helps generate PIX configuration that is more compact.
Using Interface Object in Rules
Policy rules in Firewall Builder have special rule element or column called "Interface". You can drag and drop, or copy/paste interface object into this column of a rule to make the firewall match not only source and destination address and service, but also interface of the firewall through which packets enter or exit it. The direction is defined by the setting in the column "Direction". Consider the following example:
Rule #0 is "anti-spoofing" rule which relies on the ability to define interface and direction. It matches packets with source addresses equal to the addresses of the firewall's interfaces or internal network. This packets are coming in from outside, which is determined by comparing the interface through which they enter the firewall. Packets with addresses like these can not normally come from outside, and so if they do, they must be spoofed and should be dropped. This is what this rule does, it drops and logs these packets. Rule #1 permits connections originating from the internal network going out, but it makes sure these packets enter the firewall through its internal interface.
These two rules generate the following iptables script:
Here all iptables command got "-i eth0" or "-i eth1" clause which makes iptables compare the interface and direction.
Here is what we get if we compile the same rules for PF:
# Tables: (1)
For PF, compiler generated block in quick log on eth0 clause to make the rule match interface and direction.
In case of Cisco IOS access lists, defining interface in the rule makes compiler place code generated for this rule into ACL attached to the given interface. Compiler for IOS ACL always generates both inbound and outbound access lists for each interface, but if the rule specifies both interface and direction "Inbound" or "Outbound", generated configuration goes only in to corresponding access list. Here is the output produced for the rules shown above for Cisco IOS ACL:
ip access-list extended inside_in
So far examples in this chapter demonstrated how to use interface objects to associate policy rules with interfaces to match packets crossing certain interface. Interface object can be used in "soruce" and "destination" of rules just like any other addressable object. In this case, fwbuilder replaces interface object with a set of its addresses, picking only those addresses that match address family (IPv4 or IPv6) assigned to the rule set. Here is how this looks like. We start with a firewall configuration where interface eth1 has two ip addresses, one IPv4 and another is IPv6. Note that this could be a host object as well because interface can belong either to a firewall or a host object.
Interface eth1 has IPv4 address 172.16.22.1 and IPv6 address fe80::21d:9ff:fe8b:8e94; it is used in a simple policy rule as follows:
Policy rule set is configured as a mixed IPv4+IPv6 rule set. For the iptables, compilers generate the following code:
# ================ IPv4
For PF we get the following:
# Rule 0 (global)
Since interface has two addresses, one IPv4 and another IPv6, compiler generated commands in both IPv4 section and in IPv6 section of the script, but it used only the right address of the interface in each. Other than that, interface object behaves just like a set of addresses when used in the source or destination element of a rule. It can also be used in NAT rules, here is an example:
This generates the following code for iptables:
# Rule 0 (NAT)
And for PF:
# Rule 0 (NAT)
Using Interface Object with Dynamic Address in Rules
Examples above demonstrated what happens when an interface with one or several IP addresses is used in policy and NAT rules. Lets look at the case when interface has address assigned dynamically. This means the address is unknwown to fwbuilder policy compiler when it generates configuration script. Compiler uses features of the target firewall to work around this. Here is the configration of the interface object eth0, the radio-button "Address is assigned dynamically" is checked.
The following policy rule uses interface eth0 in destination:
Here is what we get for iptables:
getaddr eth0 i_eth0
Shell functions getaddr and getaddr6 are defined earlier in the script. Generated script determines IPv4 and IPv6 ip addresses of the interface eth0 at the time of execution and then uses the values in iptables commands. If interface does not have an address, corresponding variable gets an empty string for its value and iptables command using it is skipped.
PF allows for using interface name in rules and gets its current ip address automatically. Here is what is generated for PF:
# Rule 0 (global)
We still get two separate parts for IPv4 and IPv6 because the rule set is configured as IPv4+IPv6 mix, but in both cases compiler just used interface name because its actual IP address is dynamic and was unknown at the time when configuration was generated.
Using Interface Object in Rules of Bridging iptables Firewall
In case of the "normal" iptables firewall, fwbuilder adds "-i eth0" or "-o eth0" parameter to the generated iptables command to make it match interface and direction. If radio-button "Bridge port" is turned on in the interface object, compilers use different option to make iptables match packets crossing bridge ports. Here is the interface "eth1" which is configured as a bridge port:
Consider then the following rule in the policy of the firewall this interface belongs to:
This rule matches interface "eth1" and generates the following iptables command:
$IPTABLES -A FORWARD -m physdev --physdev-in eth1 -s 172.16.22.0/24 -d 172.16.22.255 -m state --state NEW -j ACCEPT
Since interface is now a bridge port, compiler uses -m physdev --physdev-in eth1 to match it.