Session Tracking


Session tracking is key to the operation of the FireBrick. It means that filters can bet set up allowing traffic in one direction, and the reply traffic is implicitly allowed.

Session tracking involves the FireBrick following the replies to packets that are sent. The complexity of this depends on the protocol. However, a session is tracked based on one or more of :-

  1. The IP protocol
  2. The source IP
  3. The target IP
  4. For TCP/UDP, the source port
  5. For TCP/UDP, the target port
  6. For ICMP such as ping the ID
  7. The source interface
One of the jobs of session tracking is to record the decision of the routing function, and so determine the target interface and gateway.

Also, session tracking provides the means for port mapping and address translation allowing the IP and ports to be changed on the fly.

The FireBrick can track a limited number of sessions. For TCP the type of packets affect the session tracking - i.e. a RST (reset) will cause a session to be closed quickly as it has finished. Generally sessions are managed by time outs. The two key time outs (initial and ongoing) have per protocol defaults, but are also set using filters. How these are used are defined below. If the FireBrick runs out of sessions, then the packet is dropped.

Checking against an existing session is performed before filtering. If a packet matches an existing session then it is always allowed. If not then routing and filtering are considered and if acceptable a session is established.

Timeouts

In general, a session is established by a packet being sent. This is considered to be one-sided until a matching reply packet is received. While one-sided, the session timeout is the initial timeout. Once a packet is sent both ways then the session timeout is the ongoing timeout. If a session times out, then it is discarded, and any new packets are considered to be a new session.

ICMP error messages are normally associated with the corresponding session (for TCP/UDP and ICMP), and result in a shorter timeout applying until some other traffic is received.

The actual timeouts are defined the the limits appendix.

TCP sessions

In addition to the initial and ongoing timeouts, the TCP session tracking checks for a FIN sent each way, and an apparent ACK to a FIN (e.g. an ACK received one way after a FIN sent the other way). Sequence numbers are not checked for this, so packets being exchanged at the same time could mean the session tracking thinks a FIN has been ACKed when it has not. Once a FIN and apparent ACK are received both ways then a shorter timeout applies as the session is assumed to be closed.

Also, the session tracking follows any RST being sent either way. If a RST has been sent then a shorter timeout applies.

As TCP sessions are normally answered quickly, but may continue for hours without exchanging traffic (e.g. telnet), the initial timeout is normally short and the ongoing timeout is long.

Session tracking of TCP takes in to account the source and target port numbers.

UDP sessions

UDP sessions simply track the one-sided initial timeout and the ongoing timeout. As UDP is normally a transaction based message with a single response (e.g. DNS), the initial timeout is normally long and the ongoing timeout short.

Session tracking for UDP takes in to account both source and target port numbers. A UDP reply which is to the original source port but from a different target port will not match and will be treated as a different session. This can affect some protocols such as TFTP.

ICMP sessions

ICMP non errors, e.g. pings, are also session tracked. Only the initial and ongoing timeout states are considered.

The ICMP ID word is used for session tracking, and allows a sequence of pings to be treated as a single session.

Other sessions

Other IP protocols are session tracked simply on the source and target IP, as the content will depend on the protocol. The initial and ongoing timeout states are tracked, but these have long timeouts.

Filters can be set up to allow, and define the appropriate timeouts for specific protocols as necessary.

Broadcast sessions

ICMP and UDP session handling caters for the possibility that a session may be to a broadcast destination, and receive a reply from a specific IP. This is typical of DHCP requests and replies. A specific IP source will match as a reply to a broadcast destination but the ports have to match as normal.

Non sessions

Filtering also allows sessions to be flagged as bypass. This means the session is considered valid for only the one packet.

This is mainly aimed at port scans, or other situations where many thousands of sessions may be created and not properly closed.

The effect is that the reply packet is treated as a new session also, and so may fail filters unless allowed. Also the packets will be much slower at being processed as every packet is checked for filtering and possibly routing rules.

Note, that this must not be used for TCP traffic to/from the FireBrick itself as this will break the TCP stack which follows the session tracking and so stop the operation (e.g. web page access to the FireBrick itself). You have been warned.

Fragments

Session tracking will note the initial fragment which matches a session, and allow subsequent fragments with the same IP addresses and IP ID. However, only one "last fragment" is tracked per session, so intermixed fragments will not be automatically passed through sessions. Also, if the initial fragment if not received first, fragments are also not recognized as part of a session.

If a fragment is not recognized as part of a session, it is processed through filtering normally, and if allowed is sent without establishing a new session. As no session is established for misplaced fragments, they cannot be processed via port mapping rules.

Try to avoid fragments.

Session status

The session status shows the current sessions meeting a specific criteria. This is available from speed lanes, filters, or by protocol. It is also possible to list all sessions, and sessions with over 1MB or 10MB of data transfer so far. The display is only available where diagnostic view rights exist, and sessions can only be killed where diagnositic edit rights exist. The user will only see sessions where the applicable filter is one to which they have view rights (setup view rights for the default filter sessions).

The display shows the protocol, source and target ip/port/interface, filter, and speed lane applicable. It also shows the number of bytes each way, and where any mapping has been performed it shows the mapped to source and target ip and ports. A link from the session table allows an active session to be killed.