FirewallBuilder

Consider the network layout as in Figure 5.20.

Figure 5.20. Choosing Network Zones

In this example, 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 suppose we have created Network objects for each subnet and called them "subnet DMZ," "subnet A," "subnet B" and "subnet C." (Recall that spaces are allowed in object names.) For this set-up, network zones should be configured as follows:

Since the network zone for the "inside" interface consists of multiple objects, you must create a group so that you can use this group as a Network Zone object.

Table 5.1 explains the differences in the way firewall platforms interpret values in the Security Level and Network Zone parameters of the firewall interfaces.

Note that the "external" interface option may be deprecated in the future versions of the program.

In PIX, access lists must always be attached to interfaces. The policy compiler for PIX uses information about the 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 the Source and Destination of the rule with network zones of interfaces and only uses interfaces that match. This helps generate a PIX configuration that is more compact.

Policy rules in Firewall Builder have a rule element 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 the source and destination address and service, but also the interface of the firewall through which packets enter or exit. The direction of the packet is defined in column Direction. Consider the following example:

Figure 5.21. Rule Using an Interface Object

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, but that are coming in from outside, which is determined by comparing the interface through which packets enter the firewall. Packets with "internal" addresses cannot normally come from outside, and 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:

# 
# Rule 0 (eth0)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A FORWARD  -i eth0  -s 192.0.2.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 172.16.22.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 192.168.2.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 172.16.22.0/24  -j In_RULE_0 
$IPTABLES -A In_RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A In_RULE_0  -j DROP 
# 
# Rule 1 (eth1)
# 
$IPTABLES -A FORWARD  -i eth1  -s 172.16.22.0/24  -m state --state NEW  -j ACCEPT 
      

Here all iptables commands have an "-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)
table <tbl.r9999.d> { 192.0.2.1 , 172.16.22.1 , 192.168.2.1 } 

# 
# Rule  0 (eth0)
# 
block in   log  quick on en0 inet  from <tbl.r9999.d>  to any
block in   log  quick on en0 inet  from 172.16.22.0/24  to any
# 
# Rule  1 (eth1)
# 
pass in   quick on en1 inet  from 172.16.22.0/24  to any keep state
# 
      

For PF, the compiler generated a "block in log quick on eth0" clause to make the rule match interface and direction.

In the case of Cisco IOS access lists, defining an interface in the rule makes the compiler place code generated for this rule into the ACL attached to the given interface. The 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"), the generated configuration goes only into the corresponding access list. Here is the output produced for the rules shown above for Cisco IOS ACL:

ip access-list extended inside_in
! Rule  1 (eth1)
! 
  permit ip 172.16.22.0 0.0.0.255 any  
exit

ip access-list extended outside_in
! Rule  0 (eth0)
! 
  deny   ip host 192.0.2.1 any  log 
  deny   ip host 192.168.2.1 any  log 
  deny   ip 172.16.22.0 0.0.0.255 any  log 
exit

interface FastEthernet1
  ip access-group inside_in in
exit
interface FastEthernet0
  ip access-group outside_in in
exit
      

So far, the examples in this section have demonstrated how to use Interface objects to associate policy rules with interfaces so as to match packets crossing certain interface. An interface object can be used in the "source" and "destination" of rules just like any other addressable object. In this case, Firewall Builder replaces the interface object with the set of its addresses, picking only those addresses that match the address family (IPv4 or IPv6 or both) assigned to the rule set.

For example, 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 interfaces can belong either to a Firewall or a Host object.

Figure 5.22. Interface Object with Both Address Families

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:

Figure 5.23. Interface Object in a Rule

This policy rule set is configured as a mixed IPv4+IPv6 rule set. For iptables, the compiler generates the following code:

# ================ IPv4
# Rule 0 (global)
# 
$IPTABLES -A INPUT -p tcp -m tcp  -d 172.16.22.1  --dport 22  -m state \
 --state NEW  -j ACCEPT 

# ================ IPv6

# Rule 1 (global)
# 
$IP6TABLES -A INPUT -p tcp -m tcp  -d fe80::21d:9ff:fe8b:8e94  --dport 22 \
 -m state --state NEW  -j ACCEPT
      

For PF we get the following:

# Rule  0 (global)
# 
# 
pass in   quick inet proto tcp  from any  to 172.16.22.1 port 22 keep state
pass out  quick inet proto tcp  from any  to 172.16.22.1 port 22 keep state

# Rule  0 (global)
# 
# 
pass in   quick inet6 proto tcp  from any  to fe80::21d:9ff:fe8b:8e94 port 22 \
keep state
pass out  quick inet6 proto tcp  from any  to fe80::21d:9ff:fe8b:8e94 port 22 \
keep state
      

Since the interface has two addresses, one IPv4 and another IPv6, the compiler generates commands in both the IPv4 and IPv6 sections of the script, but it uses only the appropriate address in each. Other than that, the 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:

Figure 5.24. IPv4 Address Object Assigned to an Interface

This generates the following code for iptables:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth0  -s 172.16.22.0/24 -j SNAT \
--to-source 192.0.2.1 
# 
# Rule 1 (NAT)
# 
$IPTABLES -t nat -A PREROUTING  -p tcp -m tcp   -d 192.0.2.1 --dport 80 \
-j DNAT --to-destination 172.16.22.100 
       

And for PF:

# Rule  0 (NAT)
# 
nat on eth0 proto {tcp udp icmp} from 172.16.22.0/24 to any -> 192.0.2.1 
# 
# Rule  1 (NAT)
# 
rdr on eth0 proto tcp from any to 192.0.2.1 port 80 -> 172.16.22.100 port 80 
        

The examples above demonstrated what happens when an interface with one or several IP addresses is used in policy and NAT rules. Let's look at the case when an interface has an address assigned dynamically. This means the address is unknown to the Firewall Builder policy compiler when it generates the configuration script. The compiler uses features of the target firewall to work around this. Here is the configuration of the interface object eth0. The radio-button Address is assigned dynamically is selected.

Figure 5.25. Interface with Dynamic Address

The following policy rule uses interface eth0 in destination:

Figure 5.26. Interface with Dynamic Address in a Rule

Here is the result for iptables:

getaddr eth0  i_eth0
getaddr6 eth0  i_eth0_v6

# ================ IPv4

# Rule 0 (global)
# 
test -n "$i_eth0" && $IPTABLES -A INPUT -p tcp -m tcp  -d $i_eth0  --dport 22 \
  -m state --state NEW  -j ACCEPT 

# ================ IPv6

# Rule 0 (global)
# 
test -n "$i_eth0_v6" && $IP6TABLES -A INPUT -p tcp -m tcp -d $i_eth0_v6  \
 --dport 22  -m state --state NEW  -j ACCEPT 
        

The shell functions "getaddr" and "getaddr6" are defined earlier in the script. The generated script determines IPv4 and IPv6 addresses of interface eth0 at the time of execution and then uses the values in iptables commands. If the interface does not have an address, the corresponding variable gets an empty string for its value and the iptables command using it is skipped.

PF allows for using interface name in rules and gets its current IP address automatically. This is the result generated for PF:

# Rule  0 (global)
# 
pass in   quick inet proto tcp  from any  to (en0) port 22 keep state
pass out  quick inet proto tcp  from any  to (en0) port 22 keep state

# Rule  0 (global)
# 
pass in   quick inet6 proto tcp  from any  to (en0) port 22 keep state 
pass out  quick inet6 proto tcp  from any  to (en0) port 22 keep state
         

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 the interface name because its actual IP address is dynamic and was unknown at the time the configuration was generated.

In case of the "normal" iptables firewall, Firewall Builder adds an "-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, the compiler uses a different option to make iptables match packets crossing bridge ports. Here is the interface "eth1" which is configured as a bridge port:

Figure 5.27. Bridge Interface

Consider the following rule in the policy of the firewall this interface belongs to:

Figure 5.28. Bridge Interface in Rule

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 the interface is now a bridge port, the compiler uses "-m physdev --physdev-in eth1" to match it.