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

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

41
Chapter 7. Session Handling
This chapter describes sessions, session-tracking, and how the rules for session creation can be used
to implement Firewalling, subject specific traffic flows to traffic-shaping, and perform address mapping
techniques including conventional Network Address Translation (NAT).
Session-tracking is also involved in the route override functionality of the FB6000 - this is covered in
Section 8.6.
7.1. Routing vs. Firewalling
A network router is a device whose role is to forward packets entering the device out onto an appropriate
physical interface, based primarily, or solely, on the destination IP address of the packets. Typically the source
address of each packet is not considered in the forwarding decision.
A firewall on the other hand is a device whose primary role is to filter traffic based on specified criteria. Since
most network communication between two end-points is bi-directional, any such filtering must correctly handle
the packets flowing in both directions that constitute a specific end-to-end 'flow' (for connection-less protocols,
such as UDP) or 'connection' (for connection-orientated protocols, such as TCP).
In practice, a firewall appliance will have to make routing decisions too.
7.2. Session Tracking
Each flow or connection is identifiable by the set of parameters that makes it unique ; two of these parameters
are the network addresses of the two end-points. For protocols that support multiplexing of multiple flows or
connections to/from a single network address - UDP and TCP both support this - the remaining parameters
are the identifiers used to do the multiplexing. For both UDP and TCP, this identifier is a port-number, whose
scope is local to the end-point, and is therefore usually different at each end-point for a given flow/connection.
Normally, only one of the two port-numbers involved will be known a priori - this will be the documented
port-number used for a specific service at the server end (for example, port 80 for an HTTP service) ; the other
is dynamically chosen from the available pool of unused port numbers at the client end.
Therefore, the filter criteria can only specify that known port-number ; the other port-number can only be
determined by inspection of the IP packet payloads, discovering which protocol is being carried, and using
knowledge of the protocol to extract the port-number.
This information must then be stored, and held for a duration not less than the duration that communications
occur over the flow or connection. This information defines a session, and is stored in the session-table. The
key point of the session table entry is that it will then cause return traffic to be allowed, and sent to the correct
place. Without the session table entry, the FB6000 would have no way of knowing that the return traffic is part
of an allowed (by firewalling rules) session, and it would likely be dropped due to firewalling.
The overall process of analysing packet payloads and maintaining the session-table is referred to as session-
tracking.
Session-tracking is necessary to be able to implement firewalling using the kind of rules you might expect to
specify - for example :
"allow TCP connection to port 80 on IP address 10.1.2.3, from any IP address" (note source port number not
specified)
Session-tracking will therefore be present in a firewall, but not required in a router.