FirewallBuilder

Suppose we need to permit SSH access to the firewall. In the simplest case we just create a rule with a firewall object (fw) in the destination and a service object SSH in the service. The SSH service object can be found in the Standard objects tree, under Services/TCP. Here is the rule:

Figure 14.21. SSH from Anywhere

This almost-trivial rule compiles into configurations using entirely different concepts depending on the chosen target firewall platform. The generated iptables rule is rather simple:

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

The generated PF configuration uses tables to list all IP addresses that belong to the firewall:

table <tbl.r0.d> { 192.0.2.1 , 192.168.1.1 } 

# Rule  0 (global)
# 
pass in   quick inet proto tcp  from any  to <tbl.r0.d> port 22 keep state 
      

The iptables platform has a concept of chains that separate different packet flow paths inside the netfilter engine and packets headed for the firewall itself are always processed in the INPUT chain. This means the generated iptables script could be optimized. If comparison is done in the INPUT chain, the script does not have to verify the destination address to make sure it belongs to the firewall, since this has already been done by the kernel. PF does not have any mechanism like this, therefore generated PF configuration must compare destination address of the packet with all addresses of the firewall. This can be done in a more elegant way using PF tables, but still, we make the firewall compare destination address of the packet against a list of addresses.

The ipfw platform offers a shortcut for this, called the configuration option "me". Here is how the generated ipfw script looks for the same simple rule controlling SSH access to the firewall:

# Rule 0 (global)
# 
"$IPFW" add 10 set 1 permit tcp  from any  to me 22 in  setup keep-state  || exit 1
      

"me" here means any address that belongs to the firewall.

The rule #0 on Figure 14.21 matches the ssh service, which has special meaning in case of PIX. There, control to the firewall for protocols such as SSH and Telnet is configured using special configuration commands "ssh" and "telnet" instead of using generic access lists. Here is what we get when we compile exactly the same rule for PIX:

! Rule  0 (global)
! 
ssh    0.0.0.0 0.0.0.0 outside
ssh    0.0.0.0 0.0.0.0 dmz50
ssh    0.0.0.0 0.0.0.0 inside
      

The rule in this example leaves the source address "any", which is why generated PIX commands match "0.0.0.0 0.0.0.0". Firewall Builder generated the "ssh" command for all interfaces of the PIX for the same reason.

Obviously, this rule makes the firewall too open because it permits SSH connections to it from any host on the Internet. It would be a good idea to restrict it so that it permitted connections only from the internal LAN. This is easy: we just put the object "LAN" in the source of the corresponding rule:

Figure 14.22. SSH from LAN

The generated configuration for all supported firewall platforms will follow the same pattern but add matching of the source address of the packet to make sure it comes from local LAN. In case of PIX, there is only one "ssh" command attached to the internal interface because the program determined that network object used in the source of the rule matches only this interface of the firewall:

! Rule  0 (global)
! 
ssh    192.168.1.0 255.255.255.0 inside
      

This is better, but we should be careful not to permit more protocols to the firewall than we really intend to. Let's look at the simple rule permitting connects from internal LAN to the Internet (rule #0 on the screenshot below):

Figure 14.23. LAN to Anywhere

Logic says that the destination "any" should match any address, including the ones that belong to the firewall itself. In Firewall Builder, this can actually be changed using a checkbox in the Compiler tab of the Firewall Settings dialog of the firewall object. If the checkbox "Assume firewall is part of any" is checked, then the compiler generates rules assuming that "any" matches the firewall as well. So, if this option is on, then this rule permits any connections from internal LAN to the firewall, regardless of the protocol. Here is how we can modify the rule permitting access to the Internet to exclude the firewall from it using negation:

Figure 14.24. Negating the Firewall as a Destination from the LAN

We are now using negation in the destination; the meaning of this rule is "permit connections on any protocols from machines on the network 'LAN' to any host except the firewall". We still need a rule described above to permit SSH to the firewall, but the rule permitting access from LAN to anywhere does not open additional access to the firewall anymore. I am going to demonstrate the generated iptables and pf configurations for rules with negation like this later.

Is there any way to make it even more restrictive? It is always a good idea to restrict access to the firewall to just one machine and use that machine to compile the policy and manage the firewall. Let's call this machine a management station "fw-mgmt". Here is more restrictive combination of rules that permits SSH access to the firewall only from fw-mgmt, permits access from LAN to anywhere except the firewall on any protocol and blocks everything else. This combination of rules works the same regardless of the setting of the option "Assume firewall is part of any".

Figure 14.25. Firewall Access from Only One Machine

Three rules shown above are very good at restricting access to the firewall from all sources except for the dedicated management workstation. The problem with them is that the firewall policy is never this simple and short. As you add more rules, you can add a rule with a side-effect of permitting access to the firewall sooner or later. This is one of the reason many administrators prefer to keep option "Assume firewall is part of any" turned off. In any case, it may be a good idea to build rules for the access to the firewall explicitly and group them together. It would look like something like this:

Figure 14.26. Firewall Access from Only One Machine; All Other Access to the Firewall Explicitly Denied

I do not include the generated iptables, pf, pix code because it should be clear by now how should it look. It is more important that rules in Firewall Builder GUI look exactly the same regardless of the chosen target firewall platform.

Policy rules demonstrated in these examples are good at restricting access to the firewall while making it possible to manage it remotely via SSH. The problem with these rules is that administrator has to be careful to not break them in any way. One would think it should be hard to make an error in a policy fragment consisting of two rules, but this happens. These two rules are just a small part of a much larger rule set and may not be located in a prominent place right on top of it. As new rules are added to the policy, at some point some rule located above may block access to the whole network or range of addresses that accidentally includes management address of the firewall. This means even though the rules are there, the access to the firewall gets blocked as soon as updated policy is uploaded and activated. This is really bad news if the firewall machine is located far away in a remote office or data center.

To help avoid this bad (but all-too-familiar) situation, Firewall Builder offers another feature. To access it, select the firewall object in the tree and open it in the editor, then click "Firewall Settings" button. This is described in more details in Section 5.2.2. In the dialog that appears, locate controls shown on Figure 14.27

Figure 14.27. Option Enabling an Automatic Rule to Permit SSH Access from a Management Workstation

Enter the single IP as shown on the screenshot or subnet definition in the input field and click "OK", then recompile the policy. Here is what gets added on the top of the generated iptables script:

$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

# backup ssh access
#
$IPTABLES -A INPUT  -p tcp -m tcp  -s 192.168.1.110/255.255.255.255 \
     --dport 22  -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT  -p tcp -m tcp  -d 192.168.1.110/255.255.255.255 \
     --sport 22  -m state --state ESTABLISHED,RELATED -j ACCEPT
      

I included rules matching "ESTABLISHED,RELATED" states in the screenshot to demonstrate that automatic rule for SSH access is added right after them. In other words, the SSH access rule is added at the very beginning of the script before any other rule. There are actually two rules. One to Permit inbound packets in chain INPUT; it matches the protocol TCP, destination port 22, and states "NEW,ESTABLISHED". The other rule permits outbound packets in chain OUTPUT, also protocol TCP, source port 22, and states "ESTABLISHED,RELATED". The purpose of this complexity is to make sure not only newly-established SSH sessions are permitted, but also "old" ones, established before the iptables rules are purged and reinstalled during firewall configuration reload. This helps ensure that the SSH session used to activate updated firewall policy does not get blocked and stall in the middle of the policy update process.

The same option is provided in the "Firewall settings" dialog for all supported firewall platforms. Firewall Builder always generates command to permit SSH to the firewall and makes it the very first in the access control rule set.

Now all the administrator needs to do is enter the IP address of the management workstation or address block it belongs to in the "Firewall Settings" dialog, then recompile and update generated policy on the firewall. There is no need to remember to add a special rule to permit SSH to the firewall in the policy rule set since this rule is now generated automatically. The generated rule is always on top of all other rules, so any mistake in the policy rule set will never block SSH access to the firewall. This is a good way to reduce the risk of locking yourself out of your own firewall. Using this feature is highly recommended.