Implementing a Classification Policy

Introduction

The Classification policy is applied to every packet traversing the firewall.  It is applied after the packet filtering policy and (for new connections) prior to the masquerading policy.  As with the other sets of policies, the Global policy is executed first followed by the policy for the ingress zone and finally the policy for the egress zone.

It has three main uses:

• QoS classification for throttling/bandwidth control.  FireRack allows a complex hierarchical structure of QoS classes to be defined for each interface.  The classification rules can be used to associate particular traffic with different QoS classes.
• Identification and marking of packets and connections.  The classification policy is commonly used with the optional layer-7/signature match options to detect signatures in the packets within a connection and mark the connection accordingly.  Predefined signatures are available for common Peer-to-Peer protocols; custom signatures can also be used.
• Re-routing.  In situations where the firewall has two routes to the same destination via different interfaces, the traffic is normally sent to the interface with the lowest routing metric.  Re-routing rules can be used to override this for specify types of traffic.

Quality-of-Service (QoS) Classification

Prior to writing any rules for QoS Classification you need to define your QoS classes and decide how you wish to use them.

A QoS class controls the transmit rate of traffic within the class on a particular interface.  A class definition can be bound to a specific interface or be a global definition, in which case it is duplicated on every interface.  Except in very simple cases it is recommended that at least some classes are bound to interfaces.

QoS classes are defined as a hierarchy.  Each class has a guaranteed rate and a maximum rate (its limit).  The limit on a parent class may be less than the sum of the limits of its children.  In the case where the current transmit rate in all the child classes would exceed the limit of the parent, each child is permitted to use their guaranteed rate and any surplus bandwidth is shared between those that need it.

Packets can only be classified to the leaf nodes in the hierarchy, so you will need to define child classes under each parent class to cover every sub-category you require, possibly including a 'miscellaneous' sub-category.   For example, if you were to create a class for all your TCP traffic you could a sub-classes under it for each common TCP protocol such as HTTP and SMTP, and one for all other TCP traffic.

Global classes and interface specific classes can be mixed freely, except a global class cannot be a child of a interface specific class.  Typically for a complex class structure you may have a few global classes at the root of the QoS tree to cover your main categories and most of the subclasses of these would be interface specific.  In such circumstances it can be useful to have a single global subclass in each of the root classes for us as a default.  It is recommended that classes are bound to physical interfaces rather than VLAN or bridge interfaces where possible.

Traffic is categorized into QoS classes by using rules with an 'Apply QoS Class' target in the Classification policy.  Full rule matching capabilities are available in addition to signature matching so how you classify your traffic is entirely up to you.  You can for example classify by zone, by accounting realm, by protocol or ports, by IP address, by dynamic group, by peer-2-peer signature or any combination thereof.

Rules with an action of 'Apply QoS Class' are non-terminating, in that the firewall will continue to execute the policy with the next rule after applying the class.  If a subsequent 'Apply QoS Class' matches it will override the QoS class of the packet with the new QoS class.

It is recommended that the global classification policy is used first to classify all traffic into appropriate global classes.  The classification policy for the egress zones (specify a direction of 'entering zone' for the rules) can then be used to apply interface specific classes.  This helps avoid the situation where you may inadvertently apply an interface specific class to a packet which is egressing via a different interface (which would cause the packet to end up in the default class).

Packet Marking, Connection Marking and Signature Detection

A powerful aspect of FireRack is its ability to use signature matching to identify traffic outside of the limitations of protocol and port number matching.   

Packet Marking and Connection Marking can prove very useful tools for writing complex sets of firewall rules.  Packet Marking allows you write rules which if they match will associate a particular numerical value or 'Packet Mark' with the packet.  Subsequent rules can test for these values.  A 'Connection Mark' works in a very similar way but is also stored with the connection tracking entry associated with the packet.  This means that subsequent packets in the connection will also carry the same mark (unless another connection mark rule subsequently changes it).  This allows you to classify a connection based on previous packets you have seen in that connection.

Combinations of 'string match' and 'connection length match' rules can be used to identify various types of traffic mid-connection based on the presence of certain sequences of characters in the packet payload, hence providing a simple signature-based detection.  However, care should be taken when using the 'string match' option as it will search the whole of every packet it sees for the specified string, and hence it can impose a substantial load on the firewall if abused.

The Peer-to-Peer (P2P) detection module is a specialised module that allows you to write rules that match certain packets in connections belonging to one of a variety of P2P protocols.  As it is optimized to look for these protocols it is much more efficient than using string match.  A sample set of recommended P2P classification rules will be installed in the Global Classification for you on firewalls supplied with this option, but these rules can easily be tailored to suit your own requirements.

The sample rule set attempts to mark all P2P connections with the connection mark value of 200.  However, it also makes use of packet marks to avoid attempting P2P classification on connections that have already been classified as P2P.

We start by setting a packet mark of 250 on all packets for which we wish to attempt P2P classification.  By default we do this with two rules; the first one simply sets a packet mark of 250 on all TCP packets and the second clears the packet mark if the connection mark is already set to 200 .  We then follow this with a rule for each P2P type we want to detect:  all of our detection rules will first check the packet mark value is 250 and then attempt to match the P2P protocol; if they match they will change  the packet mark number to a value specific to that protocol (and thus prevent subsequent P2P detection rules being applied to that packet).

After certain detection rules there my a few rules that provide exceptions to prevent certain protocols being mis-detected.  These simply match on the packet mark value set by the P2P detection rule and also the official port number(s) of the mis-detected protocol, to change the packet mark value back to 250.

Following our detection rules we have a list of rules comprising one rule for each protocol we detected.  Each rule matches on the protocol's specific packet mark we assigned in the detection rule, and then sets the connection mark to 200.  These rules also have an additional action associated with them: they will log an event.  The events logged are defined in the 'Messages' section of 'Event Logging': each message have a maximum rate associated with it so not every connection is necessarily logged.

Following the P2P classification rules it is common to have a rule that matched on the P2P connection mark and applies a P2P QoS class.

If it is desirable to classify different types of P2P protocol separately this is easily achieved.  Simply change the connection mark values set by the rules for the appropriate protocols, and insert additional rules near the start that match on each possible connection mark set and clear the packet mark to prevent detection being attempted again on previously classified connections.  The QoS rules can then match on each different P2P connection mark and apply the appropriate classes.

Policy Based Routing

Policy Based Routing is the term used to describe making an IP routing decision using more than the traditional parameters (the destination).

Normally in the situation where your firewall has two routes to the same network (possibly the Internet) via two separate interfaces, the traffic will be routed to the interface with the lowest metric unless this interface is disabled (or off-line in the case of PPP links).  It is possible to write rules in the classification policy that override this normal decision.  As with any other rules in the classification policy, there is an extensive set of parameters that can be matched on which allows you to implement some fairly sophisticated routing policies.

Some care must be taken when using Re-Route rules.  It is important to understand that these rules only effect the routing of a packet, not what policies are applied.  Following a Re-route rule that changes the egress interface, the classification and masquerading policies for the ORIGINAL egress zone are still executed.  The firewall will not call the egress policies for any of the zones on the new egress interface.   Where policy routing is being used to route traffic between alternate Internet connections masquerading is typically required.  Connections must be masqueraded behind an IP address appropriate to the connection which they are being routed onto.  It is therefore usually necessary to proceed the masquerade rules in the original egress zone with rules that match on the same parameters as the re-route rules and will masquerade traffic with an explicit address appropriate to the connection over which it has been re-routed.