Advanced Filtering

The main FireBrick® configuration pages provide a list of filters which you can control. This list is just part of the full filtering that can be configured.

Before you can access the filtering controls you must have set the necessary security settings. See user security for details. Note that some of these features are only available on the FireBrick®Plus.

Basic principles

The internet uses three basic protocols (ICMP, UDP, and TCP), two of which have ports (TCP & UDP). These protocols are used for a variety of different applications. There are other protocols as well (over 100 of them), but these are not generally used. Messages on the internet are always sent to and from IP addresses.

If you want to control the filtering on your FireBrick®, you have to understand what you want to filter and why. In some cases you may want to make a specific operation work - a specific application for example. Usually, where there are firewalling issues, the manufacturer will provide details of firewall settings required on their web site. Real Audio is a good example where the full details of the protocols and ports used are on the Real Audio web site - but included as a default filter in the FireBrick®.

When a connection is first made between two computers - which may be from your LAN to the outside (WAN), or from the outside(WAN) to your LAN, a packet of data is sent. This establishes a session. For TCP which is used for mail, web, ftp, and many more protocols, this session is formally defined and has a start and an end. For UDP and ICMP the session is less formal and uses a timeout to tell when it has finished.

Establishing a session is what is filtered. You can control if a session is allowed to be establish or not based on the properties of that first packet (protocol, port number, IP addresses, etc). Once established, the session continues, allowing the reply packets through automatically. Even if you change the filter later, the session continues.

This means you only have to specify the filtering for the establishing of sessions. You do not have to try and set up filters that allow for the replies to established sessions. This makes the FireBrick® more secure than simple filtering without session tracking as only the exact replies are allowed rather than allowing anything that might be a reply. This also makes the FireBrick® easier to configure.

This does however mean you have to consider the direction that the session is set up. For example - web browsing by your users may seem to be data coming in to your network (and indeed they are), but the session is set up by an outgoing request. The action to get a web page is started from inside your network by someone clicking on a link and they make the session - so the direction for web page access from your users is outgoing- LAN to WAN.

A number of filters are set up by default. You can delete these filters, change them, or add to them as you wish.

Filter options

The filtering options are as follows :-

Filter setup
 
Security The security level controlling access to this filter
Name The filter name - give a meaningful name
Direction Select where the packet is going from and to.
Multiple selections can be made in each
Protocol Select the internet protocol which you wish to filter.
If you select Any, and have any ports set, then this is UDP or TCP only
Timeouts These allow the initial timeout, and ongoing timeout to be set. Leave at 0 for defaults.
Source IP Select the range of source IP addresses that much match - blank for any
Source ports Select the range of source port number - blank for any.
You do not normally need to set this as source port number is rarely relevant.
Target IP Select the range of target IP addresses that much match - blank for any
Target Ports Select the range of target port number - blank for any.
Drop Do not allow the session - ignore the packet
Allow Allow the session and all replies
Reject Do not allow the session - send back a packet indicating there is a firewall in place
Bounce Do not allow the session - send back packets to confuse the originator if possible
Blink Flash the red ALERT LED once (if lots of packets, then flashes at a steady rate while they are arriving)
Only applies when session set up, not for every packet in allowed sessions
Flash Set the ALERT LED flashing until cleared
Log Cause an internal log of the session
Syslog Send a syslog log entry
Email Cause an emailed log entry
Quick Include this filter on the main login page as a quick setup item
Suspend Ignore this filter
SYN For TCP sessions, only allow the session to be set up if this is a start of a session (SYN, no ACK)
This means that existing sessions are not re-established, e.g. after power cycling
Bypass Allow the traffic but do not set up a session. The replies are not automatically allowed.
This is mainly used where port scanning, or something generating lots of sessions
End-log Log the size of the session at the end, as per Large session but regardless of length.
Profile Control when the filter applies. Out of profile filters are ignored
TOS Restrict traffic to specific types of service (TOS). These fields are decimal mask and value. 0 is default.

Timeouts

Each filter can have two timeout values set. If 0/blank then the defaults are used. These control the initial timeout and the ongoing timeout of a session. The initial timeout applies while packets have only been seen in one direction. The ongoing timeout applies when packets have gone in both directions. These can be fine tuned for specific applications where sessions may need to be dropped quickly or kept open longer.

Ordering

All filters are considered in order from the first to the last, and as soon as as filter (which is within profile and not suspended) is found then it is applied. This means the packet is allowed, dropped, rejected or bounced. No more filters are considered once there is a match.

Always consider the ordering carefully. If a filter does not seem to be having the desired effect the look at all of the earlier filters so see if any of them could be matching. The diagnostic session tracking and log can show which filter was actually used. Feel free to delete unwanted default filters.

If there is no matching filter then the packet is handled according to the default filter rule in the setup menu (normally dropped) unless it is from the FireBrick® itself or to the FireBrick® from the LAN (inside) - e.g. access to web config pages. There is also a default first filter that ensures you are unlikely to lock yourself out. If you want to allow access from the outside for web pages, then you will have to enable the Firebrick-remote default filter as well as setting appropriate user access controls.

Your can move filters around by clicking on the green dot next to a filter and then clicking on where you want the filter to be moved to. This shuffles the intervening filters up or down as necessary.

Direction

The direction is the direction the session is established. Normally this is WAN->LAN for incoming and LAN->WAN for outgoing. The direction can include WAN, LAN, Serial, Tunnel, or the FireBrick® itself, and multiple interfaces can be selected. You should be careful of using Any (i.e. all directions selected) unnecessarily as this could cause the config web pages to become inaccessible! (see Don't Panic). Serial is for future use.

Dropping sessions

Rejecting a packet and dropping a packet are not quite the same. Rejecting a packet means that a message is sent back which effectively says "you have been firewalled" (the originator may or may not be able to tell that this is the problem). Dropping the packet simply means it does not get through. Bouncing connections simple causes confusion - but does not allow anything in to your network. Note that rejection and bounces are all delayed so that any attempt to flood you with packets does not block up you outgoing connection with your replies.