Policy compilers treat some addresses in policy rules in special ways, depending on the requirements of the target firewall platform. For example, the compiler for iptables checks if the address found in "Destination" or "Source" of a rule matches the address of any interface of the firewall to determine if the rule should be placed in INPUT or OUTPUT chain. The compiler for PIX uses the command ssh <address> <netmask>> inside when it detects such an address in the destination of a rule where the service is TCP Service object "SSH". There are other special cases as well.
Two important special cases are broadcast and multicast addresses. It is important to place rules in the correct chain in generated iptables script, because even though these addresses are not equal to those of the firewall's interfaces, iptables processes packets with broadcast or multicast destination in the INPUT chain. Firewall Builder is aware of this and generates the correct iptables commands.
In order to match broadcast or multicast addresses in the rules, we need to create objects to describe them. The choice of object type to describe broadcast or multicast address depends on whether this is just a single address, a range or a block. An address object is good for defining a single address, address range is good for sets of consecutive addresses and network object is good for describing a block. For example, you can use an address object with address "255.255.255.255" to describe a broadcast. address range with addresses "188.8.131.52 - 184.108.40.206" would work well to describe two multicast groups used by OSPF. A network object with address "220.127.116.11" and netmask "240.0.0.0" can be used to describe a whole multicast address block.
Here are few examples:
Object "all multicasts" is part of the Standard Objects library that comes with the program. It describes an entire address block allocated for multicasts. Consider a simple policy rule that permits all multicasts:
For iptables, this rule translates into the following script:
$IPTABLES -A INPUT -d 18.104.22.168/4 -m state --state NEW -j ACCEPT
The rule went into the INPUT chain because iptables processes multicast there.
Here is another example, this time it involves broadcast addresses. The interface "inside" of the test firewall has address 172.16.22.1 with netmask 255.255.255.0. This defines subnet 172.16.22.0/255.255.255.0 with broadcast address 172.16.22.255. We create an address object with the name "net-172.16.22 broadcast" and address "172.16.22.255" and use it in the destination field of a policy rule. Another rule in the same example will match broadcast address "255.255.255.255"; an address range object that defines this address is present in the standard objects library under the name "broadcast". Here are the rules:
These two rules translate into the following script for iptables:
# Rule 0 (global) # $IPTABLES -A INPUT -d 255.255.255.255 -m state --state NEW -j ACCEPT # # Rule 1 (global) # $IPTABLES -A INPUT -d 172.16.22.255 -m state --state NEW -j ACCEPT
Both rules went into INPUT chain as expected.
Compilers treat broadcast and multicast addresses differently if the firewall object is set to be a bridging firewall. In this case the checkbox "Bridging firewall" should be turned on in the firewall settings dialog and one or more interface objects should be marked as "Bridge port":
Now the rule that matches the broadcast destination address will be treated differently:
This produces the following iptables commands:
$IPTABLES -A FORWARD -d 172.16.22.255 -m state --state NEW -j ACCEPT $IPTABLES -A INPUT -d 172.16.22.255 -m state --state NEW -j ACCEPT
Rules went into both INPUT and FORWARD chains because the bridging firewall passes broadcasts through, but at the same time accepts them as packets headed for itself. Since the rule did not specify which interface it should look at, Firewall Builder assumed that the generated rule should inspect packets crossing all interfaces, both bridge ports and "normal" ones, and therefore placed the rule in both INPUT and FORWARD chains.
Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
Using free CSS Templates.