The host object in Firewall Builder is designed to represent real hosts in the network: workstations, servers, and any other network node with an address. Just like real hosts, host objects have interfaces that represent different physical connections to the network.
Most hosts have just a single (visible) interface with a single IP address. In that case the actual interface and its name do not matter. For most foreign hosts, Firewall Builder assigns an arbitrary name, like “interface1”, to the host's interface. However, by using the tree-like hierarchy of hosts -> interfaces -> addresses, it is possible to specify the exact address and/or interface of a host in cases where it does matter.
As in the Firewall object, interfaces and addresses are represented by objects that are organized in a tree. An interface can have multiple addresses. An example of a host with one interface and multiple addresses is shown in Figure 5.47. Host “test server” is located on the LAN and has three virtual IP addresses that all belong to the same interface, “eth0”.
Note that in Firewall Builder, the host object is an abstraction. It does not have to conform to an individual host. This host object may in fact represent a web farm that accepts connections on three IP addresses, each on a different computer.
The host object cannot have any access, NAT, or routing policy associated with it; only firewall objects can have policies.
To speed up the process and make it simpler, creating a new host object is aided by a wizard that is similar to the one for creating a new Firewall Objects.
To launch the wizard, selectfrom the menu or right-click and select it from there.
Section 5.2.2 shows how to use the firewall object wizard. The host object wizard is the same, with the following exceptions:
You do not specify the operating system or platform for host objects.
The Host object templates are different than those for Firewall objects. Browse through the list in Firewall Builder to see what's available.
This method works the same as for the Firewall object, though the Add Interfaces page is slightly different. You cannot tag an interface as a "bridge port" interface. You can, however, indicate it is unnumbered or dynamic by selecting the appropriate checkbox. If neither checkbox is selected, then the interface is assumed to have a static IP address. As with the firewall object wizard, you can only add IPv4 addresses in this way. If you need to use IPv6 addresses, create the host object without IP addresses and add them later.
This method works the same as for a Firewall object. The host object must have the same name as the actual device and the host must respond to SNMP.
You can always add, modify, and remove interfaces of the new host object later using controls provided in the main window and object tree view.
The Host object dialog allows you to edit the following parameters:
The host object name.
If this option is activated, the policy compiler uses the MAC addresses of all interfaces of this host in the firewall rules. Not all firewall platforms support MAC address filtering, so this option may have no effect on the generated firewall script. This is treated as a non-critical situation, and the policy compiler will only generate a warning while processing a firewall policy where such a host is used. You cannot enter the physical (MAC) address in this dialog, however. See Section 22.214.171.124.
This is a free-form text field which can be used to add comments.
When a host object is used in a rule, it acts as a group of all of the addresses that belong to all of its interfaces. The only exception is the loopback interface; the compiler skips that address when replacing the host object with its addresses.
Consider the following Host object. It has interface eth0 with two IP addresses and a MAC address, interface he-ipv6 with an IPv6 address and a MAC address, interface lo (loopback) with its own IP address and interface sit0 (tunnel) with no address.
Let's put this host object in a rule as follows:
The rule set is configured as "IPv4 only", so even though interface he-ipv6 has IPv6 address, Firewall Builder will ignore it while generating iptables commands for this rule. Interface eth0 has two IPv4 addresses and both will be used. Here are iptables commands generated for this rule:
$IPTABLES -A FORWARD -p tcp -m tcp --dport 22 -m state --state NEW \ -j Cid6066X5981.1 $IPTABLES -A Cid6066X5981.1 -d 10.3.14.44 -j ACCEPT $IPTABLES -A Cid6066X5981.1 -d 10.3.14.55 -j ACCEPT $IPTABLES -A Cid6066X5981.1 -d -j ACCEPT
Let's see what we get for the same rule if we configure rule set object as "IPv4+IPv6":
Since the rule is now configured to compile for both address families, Firewall Builder processes it twice, once for each address family. Here is what we get (these are relevant fragments of the generated script):
# ================ IPv4 $IPTABLES -A FORWARD -p tcp -m tcp --dport 22 -m state --state NEW \ -j Cid6066X5981.1 $IPTABLES -A Cid6066X5981.1 -d 10.3.14.44 -j ACCEPT $IPTABLES -A Cid6066X5981.1 -d 10.3.14.55 -j ACCEPT $IPTABLES -A Cid6066X5981.1 -d -j ACCEPT # ================ IPv6 $IP6TABLES -A FORWARD -p tcp -m tcp --dport 22 -m state --state NEW \ -j Cid6066X5981.1 $IP6TABLES -A Cid6066X5981.1 -d fe80::a3:e2c -j ACCEPT
Host and firewall objects have child interface objects, which in turn have child address and physical address objects. In fact, an interface object can have more than one associated address object. Let's see how this works:
Consider example Figure 5.52, Figure 5.53. Here interface eth0 of "test server" has three IP addresses (named "test server:eth0:0" through "test server:eth0:2") and interface eth0 of "dmz host" has only one IP address: "dmz host:eth0". Policy rule #9 says that "dmz host" can talk to "test server" using any protocol. Since "test server" has three different addresses, we need to generate policy a rule that will match any of them. (Obviously we cannot match all three at once, so the compiler uses a logical "OR", not a logical "AND" here.) Basically, rule #9 is equivalent to three separate rules, each of them using one address of "test server" in turn. These three rules are represented in Figure 5.54 (original rule #9 also shown there, but it is disabled.)
Firewall Builder takes care of this situation automatically and generates the firewall policy described in Figure 5.53 as if a user had built a policy in the GUI using the three rules as shown in Figure 5.54.
In fact, the algorithm used is even more general. In the example Figure 5.53, host "test server" has a single interface with multiple addresses that the compiler used to generate the target firewall code. The policy compiler works in a similar way even if the host or firewall object used in the rule has multiple interfaces and each interface, in turn, has multiple addresses. If a host (or firewall) object is used in the rule, then the compiler scans all its interfaces, finds all corresponding addresses, and uses them to generate the firewall configuration. If an interface object is used in the rule, then the compiler uses all its addresses. And finally, if an address or physical address object is used in the rule, then the compiler uses only this parameter to generate the firewall configuration. In other words, the compiler always traverses the tree, starting from the object found in the policy rule, and uses the parameters of all address and physical address objects it finds. Since address and physical address objects are the leaf nodes in the tree and have no other objects beneath them, the compiler uses the parameters of these objects to generate the target code.
There is an exception to this algorithm, see Section 126.96.36.199
Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
Using free CSS Templates.