In this example, we create a rule to permit our internal LAN to connect to the Internet using any protocol. The network object "net-192.168.1.0" should be configured with the IP address and netmask corresponding to those used on the internal network behind the firewall. Since the internal LAN in this example uses a private address block, the rules described here are insufficient and should be accompanied with corresponding NAT (Network Address Translation) rules. We discuss NAT rules in the next chapter.
Here are the iptables commands generated for this example:
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Rule 0 (global) # $IPTABLES -A INPUT -s 192.168.1.0/24 -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -s 192.168.1.0/24 -m state --state NEW -j ACCEPT $IPTABLES -A FORWARD -s 192.168.1.0/24 -m state --state NEW -j ACCEPT # # Rule 1 (global) # $IPTABLES -N RULE_1 $IPTABLES -A OUTPUT -j RULE_1 $IPTABLES -A INPUT -j RULE_1 $IPTABLES -A FORWARD -j RULE_1 $IPTABLES -A RULE_1 -j LOG --log-level info --log-prefix "RULE 1 -- DENY " $IPTABLES -A RULE_1 -j DROP
Rules that utilize the module state and match states ESTABLISHED,RELATED permit reply packets, such as TCP ACKs, UDP reply packets, and ICMP messages associated with known sessions. These rules are automatically added at the beginning of the generated iptables script if the option "Accept ESTABLISHED and RELATED packets before the first rule" is turned on in the firewall object "Advanced" settings dialog. If you turn this option off, the rule will not be added automatically and you'll have to add it yourself. You can use the Custom Service object ESTABLISHED, which you can find in the Standard objects library, to do this.
The first rule was placed in all three chains: INPUT, OUTPUT and FORWARD because option "Assume firewall is part of any" was turned on in the "Advanced" settings dialog of this firewall object. This option directs the policy compiler to assume that the object "Any" matches the firewall itself as well. In other words, using "Any" in the Destination of the rule is equivalent to using a combination of any address and the firewall. To match packets headed for the firewall, the rule should be placed in the INPUT chain. Also, the network object within address 192.168.1.0/24 matches one of the interfaces of the firewall that has an address on this network. This means that this rule should also match packets sent by the firewall itself, provided the source address is that of the interface on the internal net. This requires the iptables command in the OUTPUT chain. And finally, the iptables command in the FORWARD chain matches packets sent by machines on the internal network.
Rule #1 catches all other packets going to, from, and across the firewall, and logs and drops them.
Let's see what gets generated for iptables if the option "Assume firewall is part of any" is turned off:
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Rule 0 (global) # $IPTABLES -A FORWARD -s 192.168.1.0/24 -m state --state NEW -j ACCEPT # # Rule 1 (global) # $IPTABLES -N RULE_1 $IPTABLES -A FORWARD -j RULE_1 $IPTABLES -A RULE_1 -j LOG --log-level info --log-prefix "RULE 1 -- DENY " $IPTABLES -A RULE_1 -j DROP
Automatically-added rules that match packets in states ESTABLISHED,RELATED are not affected by the "Assume firewall is part of any" option and always match in the chains INPUT, OUTPUT and FORWARD.
Since the compiler does not assume the firewall matches "any" anymore, the rule with "any" is destination yields an iptables command only in the FORWARD chain. This applies both to the rule that permits outgoing connections from internal LAN and to the "Catch all" rule #1. The choice of the setting for this option is up to the policy designer. Some people find it more intuitive to leave it off and add rules to control access to and from the firewall explicitly. Note that default policy for all chains is set to DROP with the following commands at the very top of the generated iptables script:
$IPTABLES -P OUTPUT DROP $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP
This means that if you do not add rules to permit access to the firewall and turn option "Assume firewall is part of any" off, then all generated iptables rules will be in the FORWARD chain and all access to the firewall itself will be blocked by the default policy in the INPUT chain. On the other hand, if the option "Assume firewall is part of any" is on, then the rule permitting access from internal network to "any" has a side-effect of permitting access to the firewall as well. It is up to you to decide whether this is the desired behavior. You can always restrict access to the firewall and control it with a few rules somewhere close to the beginning of the policy, regardless of the setting of this option. We look at the examples of rules controlling access to the firewall in Section 14.2.10.
Even if you choose to turn option "Assume firewall is part of any" off and do not add any rules to permit access to the firewall in your policy rule set, you can use another option in the firewall object "advanced" settings dialog for this. The option is called "Always permit ssh access to the firewall from management station" and allows you to enter a single IP address or subnet; it then automatically adds a rule to the generated script to permit SSH access to the firewall from this address. We demonstrate this feature in one of the examples below.
The examples below have been compiled with the option "Assume firewall is part of any" turned on.
Here is the PF configuration created for the same rules:
# Rule 0 (global) # pass quick inet from 192.168.1.0/24 to any keep state # # Rule 1 (global) # block log quick inet from any to any
Firewall Builder always generates PF configuration using its "quick" clause to switch to the first-match mode. In this PF configuration example, the first rule permits packets with source address on the 192.168.1.0/24 network and stops processing. The second rule will only inspect packets not matched by the first rule.
Here is the fragment of the PIX config generated for the same combination of rules:
Rule 0 (global) ! access-list inside_acl_in remark 0 (global) access-list inside_acl_in permit ip 192.168.1.0 255.255.255.0 any ! ! Rule 1 (global) ! access-list outside_acl_in remark 1 (global) access-list outside_acl_in deny ip any any log 4 interval 300 access-list dmz50_acl_in remark 1 (global) access-list dmz50_acl_in deny ip any any log 4 interval 300 access-list inside_acl_in remark 1 (global) access-list inside_acl_in deny ip any any log 4 interval 300 access-group dmz50_acl_in in interface dmz50 access-group inside_acl_in in interface inside access-group outside_acl_in in interface outside
Since the source address in the rule #0 is limited to the internal network, the policy compiler was able to determine which interface the access list command should be associated with and added it only to the ACL "inside_acl_in".
The "access-group" commands are actually located at the very bottom of the generated script, after all other access-list commands. It is shown right next to the ACL rules here for presentation.
Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
Using free CSS Templates.