FireBrick FB6402, Руководство пользователя

Страница: 59 / 196

Session Handling
42
The contents of the session-table can be viewed in the web user interface by clicking "Sessions" in the "Status"
menu. You will normally see two entries per session, one with a green background and one with a yellow
background. These two 'entries' are the forward and reverse details of the session.
7.2.1. Session termination
For connection-orientated protocols such as TCP, the session-tracking is able to detect connection closure and
delete the session from the session-table.
For protocols such as UDP, which will likely be carrying a higher-level protocol that may well itself implement
some form of connection-orientated data transfers, further inspection and analysis of communications is not
done by the FB6000. To do so would require support for a very wide range of protocols that are carried over
UDP, and this is generally not practical.
Instead, all sessions (including TCP ones) have an associated time-out value - if no packets matching the session
arrive for a period equal to the time-out value, the session is deleted automatically. This is adequate for most
cases, but may require selection of a suitable time-out value based on knowledge of how frequently the higher-
level protocol sends packets. An unnecessarily high time-out may cause the session-table to become populated
with a significant number of sessions that correspond to flows or connections that have actually ceased.
However, the FB6000 has highly efficient handling of session tracking, both in terms of memory usage and
processor load, so in practice it can easily handle very large session tables (hundreds of thousands of entries).
Note that TCP sessions also have time-outs ; this is necessary since the connection may not be cleanly closed,
for example one end may crash - if there were no time-out, the session-table would hold a stale entry until the
FB6000 was rebooted.
7.3. Session Rules
7.3.1. Overview
As each packet arrives, the FB6000 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 FB6000 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 13.1 for details.