7.3. Session Rules

7.3.1. Overview

As each packet arrives, the FB2700 determines whether the packet is part of an existing active session by doing a look-up in the session table. If a matching session is found, the session-table entry details determine how the packet is handled. If no matching session is found, the list of session-rules is then analysed to determine whether a new session should be established, or whether the traffic should be dropped or rejected.

Each session rule contains a list of criteria that traffic must match against, and contains an action specification that is used in the logic to decide whether the session will be allowed or not. The session rule can also :-

  • make the session subject to traffic-shaping
  • specify that Network Address Translation should occur
  • specify that address and/or port mapping should occur

Session-rules are grouped into rule-sets, and together they are involved in a well-defined processing flow sequence - described in the next section - that determines the final outcome for a candidate session.

Tip

The FB2700 provides a method to illustrate how specific traffic will be processed according to the flow described. This can be used to 'debug' your rules and rule-sets, or simply to improve / verify your understanding of the processing flow used to determine whether sessions are established. Refer to Section 16.1 for details.

7.3.2. Processing flow

The following processing flow applies to rules and rule-sets :-

  • Rule-sets are processed sequentially.
  • Each rule-set can optionally specify entry-criteria - if present, these criteria must be matched against for the rules within the rule-set to be considered.
  • If the rule-set's entry-criteria are not met, processing immediately proceeds with the next rule-set, if any.
  • If the rule-set's entry-criteria are met, or no entry-criteria were specified, processing of the rules within that rule-set begins :-
    • Rules are processed sequentially.
    • Each session-rule specifies criteria, and an action to be taken when traffic meets those criteria ; the action values are their meanings are shown in Table 7.2. Once a rule matches, no more rules in that rule set are considered.
    • If all of the rules in a rule-set have been considered, and none of them matched against the traffic, then the action specified by the no-match-action attribute (of the rule-set) is taken. The available actions are the same as for a session-rule.

Table 7.2. Action attribute values

"action" attributeAction taken
dropimmediately cease rule processing, 'quietly' drop the packet and create a short-lived session to drop further packets matching the rule criteria
rejectimmediately cease rule processing, drop the packet, send rejection notification back to the traffic source and create a short-lived session to drop further packets matching the rule criteria
acceptimmediately cease rule processing, and establish a normal session
continue'jump' out of the rule-set ; processing resumes with the next rule-set, if any
ignoreimmediately cease rule processing, 'quietly' drop the packet but do not create a short-lived session (in contrast to the drop action)

The short-lived session that is created when either drop and reject are actioned will appear in the session table when it is viewed in the web user interface (or via the CLI) - see Figure 7.1 for an example of ICMP sessions resulting from some pings ; the session lifetime is around one second.

Figure 7.1. Example sessions created by drop and reject actions

Example sessions created by drop and reject actions

Note that drop and reject both drop packets, with the difference only being whether notification of this is sent back to the traffic source.

Tip

For a short period after startup the actions of drop and reject are treated as ignore. This is so that a reboot which would forget all sessions allows sessions that have outbound traffic which is not NAT stand a chance of re-establishing by use of outbound traffic. Without this delay, incoming traffic would create a drop/reject short lived session and could send an icmp error closing the connection. This is configurable per rule-set.

Note

It is possible to mis-understand the function of the no-match-action attribute, given where it is specified (i.e. an attribute of the rule-set object). This is particularly true when using XML. If you are unfamiliar with the FB2700's session rule specifications, you may interpret the no-match-action as specifying what happens if the rule-set's entry-criteria are not met (i.e. at the beginning of processing a rule-set).

no-match-action specifies what happens after the entry-criteria were met, and all the rules were considered, but none of them matched ("no-match") i.e. at the very end of processing a rule-set.

Caution

If all rule-sets have been considered, and no action has specified that the session should be dropped or rejected, it will be ALLOWED. The factory default rule-sets have a firewall rule with no-match-action set to drop to avoid this happening by mistake.

We recommend you use the firewall diagnostic tests to verify that you have constructed rule-sets and rules that provide the firewalling you intended. We also highly recommend external intrusion testing to verify behaviour. We also recommend that firewalling is done using the method described in Section 7.3.3.1.

This processing flow is illustrated as a flow-chart in Figure 7.2 :-

Figure 7.2. Processing flow chart for rule-sets and session-rules

Processing flow chart for rule-sets and session-rules

It is helpful to understand that a session rule contributes to the final set of information recorded in the session-table entry - a rule does not necessarily completely define what the session-table will contain, unless it is the only rule that matches the traffic under consideration. It is for this reason, that the rules contain attributes with names such as 'set-nat' - the 'set' refers to the action of setting a flag or a parameter in the session-table entry that is being 'constructed'.

It is possible, and quite common, for more than one rule (in different rule-sets) to match given traffic. In such cases, the rules generally serve different purposes - earlier ones might be for firewalling, whilst later ones might be used to subsequently assign some of the allowed-traffic to traffic-shaping. In such cases, an earlier rule will use the continue action to jump out of the earlier rule-set.

7.3.3. Defining Rule-Sets and Rules

A rule-set is defined by a rule-set top-level object. To create or edit rule-sets in the web user interface, select the "Firewall" category icon - here you will see the list of existing rule-set objects (if any), and an "Add" link next to each.

To create a new rule-set, click on an "Add" link to insert a new rule-set before the one associated with the link. This will take you to a new rule-set defintion. Editing an existing rule-set works similarly - click the "Edit" link next to the rule-set you want to modify.

As described in Section 7.3.2, a rule-set can optionally specify entry-criteria - in the web user interface, these come under the heading "Matching criteria for whole set", when editing a rule-set definition. The entry-criteria are detemined by the following attributes, all of which are optional, but if they are specified, then the criteria must be met for processing of the rules within the rule-set to occur. These are also criteria than can be specified on individual rules within a rule-set :-

  • criteria regarding where the session is originating from :-
    • source-interface : one or more interfaces
    • source-ip : source IP address, or address range(s)
    • source-port : source protocol port number, for protocols that use the port number concept e.g. TCP and UDP
    • source-mac : (on individual rules) Only matches where from an Ethernet interface. Allows the source MAC if the initial packet to be checked for the initial bytes.
  • criteria regarding where the target of the session is :-
    • target-interface : one or more interfaces
    • target-ip : target IP address, or address range(s)
    • target-port : target protocol port number, for protocols that use the port number concept e.g. TCP and UDP
  • general criteria :-
    • protocol : the IP protocol number

There are also checks for just ip being either source or target IP, interface being either source or target interface.

Note

There is a special case for RFC5735 handling of source-ip and target-ip when they are specified as IPv4 and within 0.0.0.0/8-31. In this case the check is made for same network, so if you checked for target IP of, say, 0.0.0.0/24, that would pass if the target IP is within the same /24 as the source IP. This only works on IPv4, and only on subnets, not ranges, and only on source-ip and target-ip checks. Although not in RFC5735, the same logic is applied to IPv6 for ::/32-127.

A rule-set can also be named by setting the name attribute value, and enabled/disabled under control of a profile. The comment attribute is a general purpose comment field that you can use to briefly describe the purpose of the rule-set.

Under the heading "Individual rules, first match applies", you will see the list of session-rules within the rule-set. A session-rule is defined by a rule object, which is a child object of a rule-set object.

Below the list of session-rules, you will see the no-match-action attribute, which is mandatory and has one of the values shown in Table 7.2. Recall that this attribute specifies the action to take if all of the rules in a rule-set have been considered, and none of them matched against the traffic.

7.3.3.1. Recommended method of implementing firewalling

Although there are likely numerous ways in which you can construct workable rule-sets that implement firewalling in addition to any traffic-shaping or NAT etc., we recommend that you implement firewalling as follows :-

  • create one or more rule-sets that are specifically for firewalling
    • use one rule set per interface, with the interface specified as the target-interface in the entry criteria, such that the rule-set relates to sessions "to" that interface
    • implement a 'default drop' policy on each firewalling rule-set, such that you have to list exceptions to this policy to allow sessions to the specified target interface - to implement this policy, you set the no-match-action attribute to either drop or reject
    • ensure these firewalling rule-sets appear before any other (non-firewalling) rule-sets
  • create subsequent rule-sets if necessary to perform any modifications to the session, such as NAT'ing, or to subject sessions to traffic shaping

Caution

If you have a large number of interfaces (for example, more than just WAN and LAN), you must take care that you have covered all the interfaces that need to be firewalled

Alternatively, you could have a single firewalling rule-set without any entry-criteria and with no-match-action attribute set to either drop or reject - that way, all traffic, regardless of its origin, or its characteristics, will be subject to the 'default drop' policy. A disadvantage of this approach is that you will need to specify target interfaces in every rule in order to replicate the functionality of the method described previously.

In any case, you can verify that your rule-sets function the way you intended using the diagnostic facility described in Section 16.1.

The XML fragment below shows a small firewalling rule-set for an interface, with a 'default drop' policy :-


 <rule-set name="firewall_to_LAN"
           target-interface="LAN"       
           no-match-action="drop">   1
  <rule name="web"   
        target-port="80"
        protocol="6"
        comment="WAN access to company web server"/>   2
 3
 </rule-set>

1

Rule-set is named "firewall_to_LAN". The rule-set only applies to sessions targetting the "LAN" interface, from any other interface. The action to perform when no rule within the rule-set applies, is to "drop".

2

Rule is named "web", the criteria for matching the rule only specifies that the traffic must be targetting TCP (protocol 6) port 80. The action attribute is not present, so the action defaults to "continue" - processing continues with next rule-set. Unless any subsequent rule (in a later rule-set) drops the session, the session will therefore be allowed.

3

If no rule matched the traffic, then the "no-match-action" of the rule-set is applied here - in this case the session is dropped, thus enforcing a 'default drop' policy.

Note

The FB2700 itself does not generally need firewalling rules to protect against unwanted or malicious access, as the access controls on services can provide this protection directly - see Chapter 15 for discussion of access controls.

You may want to perform some outbound traffic filtering as well. This would normally want to work the other way around to inbound filtering. With inbound you want to block all but those listed hence using a no-match-action of drop. However, for outbound you will typically want to allow all but those listed. To this end, you could create a rule-set for traffic from inside interfaces, such as LAN and a no-match-action of continue. Then include specific rules for those things you wish to block with an action of reject.

7.3.3.2. Changes to session traffic

Normally, a session table entry holds enough information to allow return traffic to reach its destination, without potentially being firewalled.

However, a session-rule can specify certain changes to be made to the outbound traffic in a session, and the session-table entry will hold additional information that allows the FB2700 to account for these changes when processing the return traffic.

For example, a session-rule can specify that the source IP address of the outbound packets be changed, such that they appear to be coming from a different address, typically one owned by the FB2700 itself. Return traffic will then be sent back to this modified address - assuming that the intention is that this traffic reach the original source IP address, the FB2700 will change the destination IP address in return traffic to be the original source IP address. It can do this because it has stored the original source IP address in the session table entry.

The set-source-ip, set-source-port, set-target-ip and set-target-port attributes request this kind of change to be made.

Note

The set-source-ip and set-target-ip value is normally a single IP address. However a range or prefix can be specified instead. If this is used then the IP that is set will be in the range/prefix but offset from the base depending on the offset withing the matching rule that matched the IP. This means matching in the rule and not the rule-set so may mean duplicating the matching source/target ip setting. E.g. if you match a /64 prefix, and then set a new IP with a /64 prefix, it will map to the same last 64 bits. This allows general prefix mapping, and allows things like NAT64 mapping a /96 of IPv6 space to all of IPv4 space, for example. If the set ip is an IPv4 range not a power of 2 prefix then the last 32 bits of the offset from the matching range is used, modulo the target range size.

Note

Any rule that changes part of the "session" will affect the matching criteria in subsequent rule-sets and rules - i.e. they test the changed version of the session.

Quite separately to firewalling and session tracking, the FB2700 has to route traffic, and this is done using normal routing logic (see Chapter 8). The routing is done based on the destination IP address, as normal. However, it can be useful for session tracking rules to override the normal routing. The set-gateway allows a different IP address to be used for the routing decision, instead of the actual destination IP in the packets. Setting this causes all subsequent packets matching the session to use that gateway IP for routing decisions.

7.3.3.3. Graphing and traffic shaping

The set-graph and set-reverse-graph attributes cause the session traffic to be graphed, and therefore possibly be subject to traffic shaping ; they perform the same function as the graph attribute that can be specified on many different objects, as described in Chapter 10.

Each direction of the final established session can have a graph set. The normal set-graph attribute sets the forward direction graph, and set-reverse-graph sets the reverse session graph (remember, sessions have two sides). Because of this, with set-graph, the graph "Tx" direction will be the direction in which the session was established, and the "Rx" direction is therefore the opposite direction. With set-reverse-graph, the "Tx"/"Rx" directions are swapped compared to using set-graph.

There is also an option for set-graph-dynamic which causes the session to set a (forward) graph that is based on the MAC address of the source packet, if from an Ethernet interface, or the source IP. The graph is created if it does not exist. If set-graph is also defined then each new session created also causes the speed settings and long term shaper parameters to be copied from the named graph (in set-graph) to the MAC named graph being used. This is aimed at management of open WiFi and the like, allowing a named shaper to be defined and a copy of its settings created for each client based on MAC address.

7.3.3.4. Configuring session time-outs

As discussed in Section 7.2.1, each session-table entry has a timer associated with it - this ensures that inactive sessions are removed from the session-table. Two time-out values are configurable :-

  • Initial time-out : this time-out period begins when the first reply packet of the session arrives at the FB2700 ; it is specified by the set-initial-timeout attribute.
  • Ongoing time-out : this time-out period begins when each subsequent packet of the session arrives at the FB2700 ; it is specified by the set-ongoing-timeout attribute.

Note

The actual timeout used is taken from a list of timeouts, and set to the next highest available value. The status/sessions list shows the timeout in force as well as useful flags for session started, and closed, and so on.
  • The session timeout is actually maintained separately for each direction, and only when the timeout happens in both directions does the session get dropped. This allows one-sided keep-alive packets as often used by protocols such as VoIP.
  • The ongoing-timeout is set for both directions at once, only when both directions are considered to have started. The initial forward packet does not count as starting, but a further packet does. An ICMP error packet does not count to start a session either, and neither does a TCP packet that does not carry the ACK bit. These subtleties are designed to better handle unresponsive TCP endpoints and spoofed TCP packets even if allowed through the firewall.
  • There are default timeouts for UDP, TCP, ICMP, and other protocols. For UDP the timeout also depends on the target port with port 80,443, and ports 1024 and higher getting a longer timeout as per RFC recommendations (see Table 7.1).

7.3.3.5. Load balancing

Session tracking rules can include an additional set of share records which define a choice of possible changes to make when setting up the session. This choice is normally random and based on a weighting for each choice.

This allows various forms of load balancing to be applied. E.g. you could port map to one of a set of web servers or mail servers.

Each share can also have a profile which can be used to exclude the option from the selection - this is typically tied to a ping or some other test to confirm the choice makes sense. In the example of web services being load balanced, a ping based profile could confirm each web server is actually up.

Normally the choice is random, but there is an option (hash) which can be set to make the choice determined based on a hash of the source and target IP address. This allows consistent mapping of sessions to the same server. As the choice depends on the set of servers which have an active profile, if the profiles change, sessions will get a new consistent mapping based on IP addresses.

7.3.3.6. Clashes

It is possible for the creation of a session tracking entry to clash with an existing entry. This happens where the reverse session already exists. It cannot happen where the forward exists as in that case the traffic is mapped based on the existing session.

For example, if you had a session mapping traffic from an IP (A) port 5060 inside, to an IP (B) port 5060 outside, using NAT, so changing to be from the FireBrick's IP outside (C) random port to the target (B) port 5060, this creates two sides to the session, A->B one side, and B->C the other (reverse side), and allows traffic both ways.

Now, if you had a new session from outside (B) port 5060 to the FireBrick's IP (C) port 5060 which you want to map to (A) port 5060, you have a problem. The reverse (A) port 5060 to (B) port 5060 exists already, so the new session could not be created.

Normally, in the case of a clash with an existing session like this, the new session is not created. However, when the IPs are the same (in this example, A and C), and it is UDP, And the source port matches, then the original session is dropped and a new one created. This is primarily to assist NAT.

The other case where the existing is dropped and a new one created is were the existing clashing session is one sided, i.e. to drop or reject traffic.

7.3.3.7. NAT-PMP / PCP (Port Control Protocol)

The FireBrick supports protocols that allow devices on your LAN to request port mapping and firewall holes using RFC6886 (NAT-PMP) and RFC6887 (PCP). These are newer protocols than uPnP (univeral plug and play) and used by many devices and applications. PCP is the later protocol and allows handling of IPv6 and also allows finer control such as opening a firewall hole for a specific block of external IPs only.

It is importamt to understand that there are two stages to the use of these protocols. Firstly a device on the local network will send a message to the FireBrick as the gateway device requesting a mapping or firewall hole. Secondly, a session may be created that matches that mapping or firewall hole, and needs to be allowed or not accoridng to normal firewall rules.

The first stage is controlled by a setting on the subnet. By default, any subnet marked as nat="true" has pcp true as well, as does any subnet created using IPv6 Prefix Delegation. Settings on the interface and subnet can override these defaults. Only if a subnet has pcp set will a NAT-PMP or PCP packet be accepted and processed to create mappings.

Once created, the mappings can be viewed on the status page for sessions. When a new session starts it is checked against these mappings. The mappings may relate to incoming traffic or outgoing traffic. The mapping is applied to the new session, so, for example, incoming traffic to a specific mapped external port may be mapped to an internal device IP and port. This mapped traffic is then processed via the firewall rules as normal, but as it is already mapped it allows the firewall rules to consider the target (typically a private) IP address and port. This allows much finer control than would be possible otherwise, and one can, for example, easily allow all mapped traffic to specific internal devices such as gaming consoles.

In order to make the firewall rules easier to manage, any mapped traffic using a NAT-PMP/PCP rule will be flagged as pcp and so you can make rules relating specifically to these mapped sessions. As such a rule to allow all incoming mapped sessions is simple to create.

It is important to note that by default, on factory reset, the firewall rules block all incoming sessions to the LAN, and this will mean that even mapped sessions set up using NAT-PMP or PCP will also be blocked. An additional rule is necessary to allow such sessions. This rule can test for destination IPs even where these are private IP addresses on the LAN as the mappings are already applied before checking firewall rules. This means the FireBrick can be set to allow NAT-PMP and PCP sessions only for specific devices, ports and protocols by using firewall rules.

Tip

The factory default config has a rule that is set to disabled profile. Simply changing this to not have a profile will allow all mapped traffic into your LAN.

Note

NAT-PMP and PCP have no authentication. Any device on your LAN can send a message to create mappings. Whilst the FireBrick does not allow the PCP third party option, it is possible for packets to have spoofed IP and even MAC addresses to open ports to other devices. As such a blanket acceptance of all mappings is a security risk, and ideally you should consider which mappings you wish to apply.

Note

NAT-PMP and PCP can set up outgoing connections as well as incoming. These would typically be allowed through a firewall, but this allows long timeouts, so for example a long timeout outgoing UDP session could be created that then allows traffic back the other way for way longer than might otherwise have been expected. Obviously firewall rules can be used to check outgoing NAT-PMP/PCP sessions and these can even override the timeouts requested by NAT-PMP/PCP.

Tip

With pcp allowed on a subnet you can see what mappings are created, and then carefully decide which mappings you wish to allow in firewall rules.