Firewall Builder Access Control

• Running multiple services on the same machine on different virtual addresses and different ports
• Controlling access to different ports on the server
• Using firewall as DHCP and DNS server for the local net
• Permit internal LAN to connect to the Internet
• Controlling access to the firewall
• Controlling outgoing connections from the firewall

Running multiple services on the same machine on different virtual addresses and different ports

Here is another example of how Firewall Builder can be used to build a firewall protecting a server. Suppose we run several secure web servers on the same machine and use virtual IP addresses to be able to supply different certificates for each one.

In addition to that, we run webmin on the same machine that we use to manage it. We need to permit access on protocol https to virtual addresses web servers are using from anywhere, and limited access to the webmin port on a specific address.

Here is the Firewall object:

And here are the global policy rules:

Access to webmin service is only permitted from the local network, while access to the secure web servers running on virtual addresses fxp0-ip1, fxp0-ip2 and fxp0-ip3 is permitted from anywhere.

The following screenshot illustrates how the TCP Service object webmin is created.

Webmin uses port 10000, so we put this port number in both the beginning and end of the destination port range. We do not need to do any inspection of the TCP flags and leave all of them unchecked in this object.

Controlling access to different ports on the server

Firewall Builder can be used to generate policy for the firewall running on the server. Here is an example that shows how to set up policy to permit access to different ports on the server. First of all, we need to create a Firewall obejct to represent our server. The only difference between this object and a usual case where firewall protects one or more networks behind it is that for the server-firewall we only need to create one interface besides the loopback. All rules can be added to the global policy. The following screenshot demonstrates policy that permits access to the web server running on this machine(both HTTP and HTTPS), as well as FTP and management access via SSH. Rule #1 allows the server to use DNS for name resolution.

Sometimes the web server should be bound to a several IP addresses on the same machine. One typical situation when this is needed is when the web server supports multiple sites using HTTPS protocol. The following firewall configuration demonstrates the case when interface eth0 has two IP addresses (192.0.2.1 and 192.0.2.2):

Suppose the web server should accept HTTPS connections to both IP addresses, while HTTP and FTP are allowed only on address 192.0.2.1. The management access to the server is allowed only via protocol SSH and only from the management workstation fw-mgmt The following rules enforce this policy:

Note:

The same rules could be used to permit or deny access to different ports on the server located on the network behind dedicated firewall.

Using firewall as DHCP and DNS server for the local net

It is often convenient to use firewall as DHCP and DNS server for the local net, especially in small installations like that in a home office. It is not really difficult but building rules properly requires understanding of how DHCP and DNS work.

The following combination of rules permits machines on the local net to use firewall as DHCP server:

The first rule permits two types of DHCP requests: the initial discovery request which is sent to the broadcast address 255.255.255.255 and the renewal request which is sent to the firewall's address. The address range object broadcast can be found in the “Standard” objects tree, under Objects/Address Ranges; this object defines broadcast address 255.255.255.255. The second rule in the pair permits DHCP replies sent by the firewall.

We could make these rules more narrow if we used internal interface of the firewall in place of the firewall object and placed these rules in the policy associated with that interface (that's “Policy” object right under the interface object in the tree). Assuming interface eth0 is connected to internal net, the rules would look like this:

The Service group object DHCP can be found in the “Standard” objects tree under Services/Groups.

To permit local net to use firewall as a DNS server we need to permit DNS queries directed to the firewall, DNS replies sent by the firewall, as well as DNS queries sent by the firewall to servers on the Internet and replies sent back to it. The following pair of rules does just that:

The Service object group object DNS can be found in the “Standard” objects tree, under Services/Groups. This group consist of UDP object domain and TCP object domain. Both objects define destination port 53 and ignore source port. Since we do not specify the source port, these objects match both queries sent by the domain name server (source port is 53) and the resolver on the workstations on the local net (source port is >1024). We need to use objects representing both UDP and TCP protocols because DNS falls back to TCP if the answer for the query is too big and won't fit in the standard UDP datagram. DNS zone transfers also use TCP protocol.

Note: The “Help me build policy” druid (wizard) can automatically add rules described in this example.

Permit internal LAN to connect to the Internet

In this example we create a rule to permit our internal LAN to connect to the Internet using any protocol. Network object “LAN” should be configured with the IP address and netmask corresponding to those used on the internal network behind the firewall.

Controlling access to the firewall

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

Unfortunately this rule makes our 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 should be easy, we just put object “LAN” in the source of the corresponding rule:

This is better, but we should be careful not to permit more protocols to the firewall than we really intend to. Lets look at the simple rule permitting connects from internal LAN to the Internet:

Logic says that 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 checkbutton in the “Firewall” tab of the firewall object dialog. If the button “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 rule permitting access to the Internet to exclude firewall from it:

We are now using negation in the destination; the meaning of this rule is “permit conenctions on any protocols from machines on the network 'LAN' to any host except the firewall”.
But is there any way to make it even more restrictive? Of course there is. 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. Lets call this machine a management station “fw-mgmt”. Here is the rules I like best:

Controlling outgoing connections from the firewall

This example shows the rule that permits only certain types of outgoing connections. To permit outgoing web access but nothing else, we put firewall object in the Source and corresponding service object in the Service:

The rule #1 that blocks packets going from any source to any destination also blocks packet originated on the firewall (provided option “Assume firewall is part of any” is on). The combination of these two rules permits only outgoing HTTP connections from the firewall and nothing else.

Although we permit outgoing HTTP connections here, we should probably permit outgoing DNS queries as well. The browser running on this machine would not be able to connect to any web site if it can not resolve it name via DNS. Here is the corrected policy:

Service object “DNS” can be found in the “Standard” objects tree under Services/Groups.

We may also want to permit protocols used for troubleshooting, such as ping. In order to permit it, we just add ICMP Service object “ping request” to the list of services permitted by the rule #0:

Note: in Firewall Builder a firewall object represents any machine that runs firewall software. This is not necessarily a dedicated firewall protecting local net, it actually might be a server or a laptop as well. For example, rules permitting http to the dedicated firewall machine may not be very practical because running the web server on it would be risky, but if the firewall object represents a web server with iptables or ipfilter running on it, such rules make perfect sense. The rule permitting outbound HTTP access from the firewall machine which is explained in this example can be used as a part of the policy protecting a laptop or a workstation.