| 7.3. Session Rules | ||
|---|---|---|
 | Chapter 7. Session Handling |  |
| 7.3. Session Rules | ||
|---|---|---|
| | Chapter 7. Session Handling | |
As each packet arrives, the FB2500 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 FB2500 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 14.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.
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 FB2500'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.
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 :-
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 14.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 FB2500 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 13 for discussion of access controls.
**TBC add section on 'outbound' firewalling? **
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 FB2500 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 FB2500 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 FB2500 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.
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.
A caveat to this is that set-nat just sets a flag, causing the source IP address and port number to be picked at the end
of rule set processing, so the new source IP address or port number used for NAT cannot be tested for in later rule-sets.
Network Address Translation (NAT) works in exactly the same way, except that rather than specifying which address to map the original source IP
address too, the FB2500 will use an appropriate source IP address given where the traffic needs to be routed to. Furthermore, NAT will also modify the
protocol source-port number (applicable to UDP or TCP sessions) to become an unused local (to the FB2500) port number. This gives the session a completely
new source identity from the far-end point of view. NAT is requested by setting the set-nat attribute to true
As mentioned in Section 6.3.1, a subnet definition has a nat attribute, which can be set to true
to enable NAT for all sessions originating from that subnet - this is a shortcut that can be used instead of creating a session-rule to achieve this, and is useful
for RFC1918 private IP subnets.
Finally, if NAT is not requested using either of these methods, and the session is going to PPP connection or dongle that has its nat attribute
set to true then NAT is requested. This is again a shortcut for such devices that can be used if they only have one routed IP address.
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.
With set-graph, the graph "Tx" direction will be the direction the session was established in, and the "Rx" direction is therefore
the opposite direction. With set-reverse-graph, the "Tx"/"Rx" directions are swapped compared to using set-graph.
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.Both of these time-outs are specified as an XML Period value - refer to Section 4.1.3 for details on this syntax.
| |  | |
| 7.2. Session Tracking |  | Chapter 8. Routing |