| 7.3. Session Rules | ||
|---|---|---|
 | Chapter 7. Session Handling |  |
| 7.3. Session Rules | ||
|---|---|---|
| | Chapter 7. Session Handling | |
As each packet arrives, the FB2900 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 :-
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.
The FB2900 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 15.1 for details.
The following processing flow applies to rules and rule-sets :-
no-match-action attribute (of the rule-set) is taken. The available actions are the same as for a session-rule.Table 7.1. Action attribute values
| "action" attribute | Action taken |
drop | immediately cease rule processing, 'quietly' drop the packet and create a short-lived session to drop further packets matching the rule criteria |
reject | immediately 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 |
accept | immediately cease rule processing, and establish a normal session |
continue | 'jump' out of the rule-set ; processing resumes with the next rule-set, if any |
ignore | immediately 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.
Note that drop and reject both drop packets, with the difference only being whether notification of this is sent back to the traffic source.
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.
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 FB2900'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.
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 :-
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.
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 a "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 critera than can be specified on individual rules within a rule-set :-
There are also checks for just ip being either source or target IP, interface being either source or target interface.
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.1. 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.
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 :-
no-match-action
attribute to either drop or rejectIf 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 15.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"> 
<rule name="web"
target-port="80"
protocol="6"
comment="WAN access to company web server"/> 
</rule-set>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". | |
Rule is named "web", the criteria for matching the rule only specifies that the traffic must be targetting TCP (protocol 6) port 80.
The | |
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 |
The FB2900 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 14 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 block all but those listed hence using
a no-match-action of drop. However, for outbound you will typically want a
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.
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 FB2900 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 FB2900 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 FB2900 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.
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.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 FB2900 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.
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.
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 :-
set-ongoing-timeout attribute.set-initial-timeout attribute.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 has 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.
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 protcols 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.
| |  | |
| 7.2. Session Tracking |  | 7.4. Network Address Translation |