Defining Firewall Policy

A significant design parameter for FireRack was that it should be suitable for use on untrusted networks.  Traditional network firewalls only protect a network perimeter, and thus provide no protection from internal computers.  College networks and data centre networks are the obvious examples of where a perimeter firewall is insufficient, and these networks typically play host to many independently (miss)managed computers.  However, the same issues can be now seen on some large centrally-managed networks due to increasingly widespread malware such as worms and trojans.

The most basic architectural feature FireRack has for managing untrusted networks is compartmentalisation.  A network is divided into multiple security zones.  Each security zone has its own set of firewall rules.  Fundamental to the design of FireRack is that you cannot compromise the security of a zone by writing rules in another zone (except the Global zone).  Each zone can therefore be considered to be a 'virtual firewall'.  It is possible to safely delegate control of the firewall rules for a security zone to a third-party; thus the person responsible for administering the computers within a security zone may be given control of the firewall rules for those computers.

State-full Packet Inspection and Connection Tracking

The firewall maintains an internal state of current IP 'connections' it has seen before, and how it decided to handle them.  Each individual packet received by the firewall is analysed to see if it belongs to a connection the firewall has seen before.  This works for TCP and also UDP and ICMP.  UDP and ICMP are strictly speaking connection-less protocols, but the firewall nevertheless relates UDP and ICMP packets with previous ones in the same flow and thus treats them as a pseudo-connections.

Connection Tracking means that in most cases the firewall administrator only needs to consider what happens to the first packet in the connection, or in simpler terms they can just consider the connection itself.  The 'Connection Filtering' policy governs what new connections are permitted to traverse the firewall.  Once a new connection has been permitted all subsequent packets that are part of that connection are automatically allowed through the firewall in both direction.   The 'Services' policy, which governs access to the firewall's own services, and the 'Redirection' and 'Masquerading' policies, which govern Destination-NAPT (Network Address and Port Translation) and Source-NAPT respectively, are also connection based.   Conversely, the 'Packet Filtering' and 'Classification' policies, which are for advanced configurations, apply to every packet traversing the firewall and do not directly use connection tracking.

Ingress and Egress Zones: The Double-Checking Principle

The fundamental design of the FireRack firewall policy is that in order for a new connection to be allowed through the firewall it must comply with the policy of both zones involved.  Restrictions in one zone's policy cannot be circumvented by a more permissive policy in another zone.

The security zone from which the connection or packet is coming is called the 'Ingress Zone'.  The zone to which it is destined is called the 'Egress Zone'.

Since any zone can act as an ingress zone or an egress zone at any time (in some cases the ingress and egress zones are the same), all rules in a security zone are defined with a direction.  This allows different policies for incoming and outgoing connections to be defined easily.  The direction specification can be 'to the zone', 'from the zone' or 'either direction'.  For a new connection to be permitted, the Connection Filtering policy for the ingress zone must contain a rule that accepts that connection 'from the  zone' (or in 'either direction'), and the egress zone must contain a rule that accepts the connection 'to the zone' (or in 'either direction').

The 'Global Security Zone'

The 'Global Security Zone' is a special case, and is not really a true security zone.  It allows you to define a policy that can circumvent the rules for every security zone.

The global security policy is always applied before the policies for the ingress and egress zones.  If a connection is blocked by the global policy it is never permitted regardless of the policies of the zones.  If a connection is accepted by the global policy then it is always permitted regardless of the policies of the zones involved.  Typically the global filtering policy is just used for implementing universal blocks e.g. on known malware traffic.

Defining Security Zones

In its simplest case, a security zone is a single subnet specification bound to an interface.  New zones can be defined in the 'Interfaces and Zones' section of the management console.  Although multiple zones can be bound to the same interface, such that multiple subnets share the same network, better compartmentalization of security is obtained using separate interfaces on independent networks or VLANs.

In more advanced cases, proxy-ARP can be used to obtain greater compartmentalisation without the need to re-address hosts.  To segregate a host or group of hosts from other hosts in the same subnet as them, you can create a security zone specifically for them on a different interface or VLAN, and move the hosts to that network or VLAN.  This zone has the subnet assigned to it, but the standard subnet route is disabled in the zone configuration, and host specific IP routes are added for those hosts within the zone.  As the firewall determines zone membership by the IP routing into a zone, the firewall automatically treat those IP addresses as belonging to that zone.  By enabling proxy-ARP on the interfaces for both networks the firewall will transparently route the subnet between them.   This is extremely useful for server hosting on public IP addresses as each server can be isolated in its own VLAN with its own security zone without wasting 3/4 of the IP addresses on network, broadcast and gateway addresses.

Firewall Phases

The firewall policies are applied in multiple phases, which are executed in the following order:

1. Redirection (DNAT or DNAPT)
2. Filtering
3. Classification
4. Masquerading (SNAT or SNAPT)

Each phase checks three policies before moving on to the next phase:

1. Global policy.  If a rule matches in this policy the following two policies are skipped.
2. Ingress zone's policy. 
3. Egress zone's policy

The filtering policy is where traffic is where traffic is permitted through or blocked by the firewall, and comprises two parts: Connection Filtering (CF) and Packet Filtering (PF).  These are applied together as a single policy for new connections, thus the execution order is Global CF, Global PF, Ingress CF, Ingress PF, Egress CF and Egress PF.

• Connection Filtering is the main part of the firewall policy, and is used to govern what new connections are permitted through the firewall.  The default policy is to DROP the packets.  When a new connection is permitted by an 'ACCEPT' rule, it enters the 'established' state and all further packets in that connection are automatically allowed through CF.
• Packet Filtering is used in special cases.  The PF policy is applied to all new connections and all packets within established connections that have been permitted through the CF policy.  It can therefore be used to manipulate, log or break a previously established connection.  The default policy is to ACCEPT the packet and permit it to pass.

Network Address (and Port) Translation is performed in the Redirection and Masquerading policies.  In both cases the default policy is to perform no translation. 

Unlike the filtering policies, the address translation policies are only executed as far as the first matching rule.  A connection can only be redirected once, hence if a redirect rule in the Ingress Zone policy matches then the Egress Zone Masquerading policy is never executed.  Likewise, if a masquerade rule in the Ingress Zone policy matches then the Egress Zone Masquerading policy is never reached.  As with filtering, if a rule matches in the Global policy then neither zone specific policy is reached.

Additional care should be taken with redirection.  Changing the destination of a connection can change the egress zone.  In subsequent phases, the next being Filtering, the new egress zone will be used and the policy for the original egress zone is not used.  These phases will also see the translated destination address and not the original address: it is not possible to automatically distinguish between connections that were always destined to a particular address and those which are destined to that address as the result of redirection rules.

The classification phase is applied to every packet, and can be used for QoS, advanced classification (e.g. signature based classification) and policy routing.  More information is available in the document "Implementing a Classification Policy".