Filtering

Traffic filtering is the main job of any firewall - it defines what is allowed and what is not allowed.

The filtering rules for the FireBrick apply when setting up a new session. Once a session is established, the reply traffic, and further forward traffic on that session are permitted without re-checking the filtering rules.

Packets are checked as follows :-

  1. Session tracking to confirm if part of an established session
  2. Routing if not stealth
  3. Filtering
  4. Port mapping, and re-routing
Filtering itself operates on the following criteria, finding the first filter which matches, and then applying the various flags and options of that filter. A filter can be out of profile or suspended, in which case it is skipped :-
  1. Source interface - this is where the packet is from
  2. Target interface - this is where a stealth packet it to, or where routing has determined the packets destination
  3. TOS (mask and value check)
  4. Protocol
  5. Source IP
  6. Target IP
  7. For UDP/TCP, source port
  8. For UDP/TCP, target port
  9. For ICMP, type and code
  10. For TCP, an optional SYN check (i.e. TCP packet must have SYN and not ACK to pass)
Having found a filter, the filter itself can dictate the applicable session tracking timeout, and also the basic action. The filter also dictates the logging options.

No match

If no filter matches, then :-
  1. Packets from the FireBrick are silently allowed
  2. Packets to the FireBrick from the LAN are silently allowed
  3. TCP packets without SYN but with FIN or RST are silently dropped as these are normally trailing packets from closed TCP sessions
  4. Other packets are processed using the default filter rules in the log/filter options

Ports

If ports are specified in a filter, then they apply as a port range for TCP or UDP traffic, and as code and type ranges for ICMP traffic. However, if the protocol ANY is used and port ranges are specified, then the protocol must be TCP or UDP only. ICMP, and other protocols will not match. This is because it makes sense to have port ranges for either TCP or UDP as many protocols have the same ports for both - however there is no correlation with TCP/UDP ports and ICMP type/codes.

Actions

There are 4 basic actions :-
 
Drop The packet is simply ignored
Allow The packet is allowed, and a session created
Reject An ICMP admin prohibited filter message is returned
Bounce For echo, an echo reply is returned
For TCP SYN+noACK, a SYN+ACK with window 0 and MSS=0 is returned
Otherwise dropped

TCP

TCP has some special handling. The filter can have a SYN-ONLY flag meaning that a filter will only match if SYN+noACK is set.
A filter will in any case only match if FIN and RST are not set. This allows a session to be resumed after a timeout (if there is no address translation) by further normal data in the direction allowed by the filter.
If rejecting a TCP request which is not SYN, then a RST is sent if the packet is routed or known to be for a MAC on the far side.

Delay

Reject, RST, and bounce replies are all delayed so as to ensure that these are low priority packets. For example, this will give randomly delayed response times for pings if the FireBrick is set to bounce pings.

Fragments

Fragments have to be filtered if they cannot be matched to a session. If a fragment is checked against a filter, then the filter must not require a specific port range. i.e. a filter for UDP/TCP which can contain a port range will not match a fragment. This is simply because a fragment will not include the port numbers to be checked.

What the FireBrick sees

It is worth bearing in mind that the FireBrick will only see packets that it is sent. If you have a FireBrick in stealth mode, then attempts to send packets to machines you don't have will result in failed ARPs which are not logged. This means the packet which you may well have wanted to log will not actually ever be seen by the FireBrick and so not logged. You can arrange proxy ARPs for this if you want to log everything.

Traffic from the FireBrick

It is important to note that traffic from the FireBrick does not have a source address set when initially filtered. As such, checking for traffic from the FireBrick should always be done using the source interface rather than checking for a FireBrick source IP address. The source address is set before port mapping.

Port mapping

Filtering is done before port mapping, and as such the filter settings must reflect the addresses and interfaces that apply at that point.