Logging

Logging is generated as a result of a filter being activated (at the start of a session), the end of a long session and at various key events in the operation of the FireBrick. In all cases the method of logging is based on a number of options. For filters, these are specified in the filter. For other events these options are specified in the log/filter options in the set up.

The FireBrick has a 128KB internal log buffer holding recent logs entries. This buffer is also used for all upload and download, and so is cleared whenever new software or configs are loaded or the config saved.

Log options

The following actions can be selected in any combination.

Blink

One of the logging options is to blink the LED on the front of the FireBrick. This will blink once, but the rate is limited, so continuous blinking log events will result in a rapid flashing of the LED.

Flash

Another log option is to start the LED flashing. This will then flash at a slow rate until the event is cleared. The time of the event that first starts the LED flashing is recorded so that this is visible even if the log has filled and lost the event.

Memory log

The FireBricks internal log memory is used to record log events, with a time stamp (if the time is set). When displayed, it is displayed in local time, so if viewing a log covering the change from winter to summer time, all entries will show with summer time even those before the change. The heading shows the UTC offset that applies to the log.

Syslog

An event can be marked to generate a syslog entry. The local0-7 syslog options can be selected and the syslog server. This is useful for making a permanent record of some events.

Email

An event marked for email will also cause the event to be logged in the memory log, but not displayed until the memory log option was also selected. As such emailed events take space in the log.

The email system then monitors the log continuously for an emailable event. When this happens a pre-email delay applies, and then the email is sent. All entries up to the current time that are emailable are sent in the email. If sent correctly, then all of these entries are marked as not emailable to avoid duplication and the log monitoring continues after a post-email delay. If the email fails, then the monitoring stays at the same point to try again.

Email can be sent to a specified IP address using a specified sender and recipient using normal SMTP. Sending or failing to send an email is also logged, but this has the email option removed to avoid self generating email logs.

End-log

A filter can have a flag causing the "large session" logging to be applied regardless of the length of the session.

Filter logs

Log entries simply consist of a text line, which usually includes the relevant IP address, etc. Filter logs contain more detail and help allow filters to be constructed to allow or disallow specific types of traffic.

Colour coding

Most log entries are shown in black. Filter log entries are shown in Black, Green, Red, or Blue depending on whether the filter was Drop, Allow, Reject, or Bounce. This helps identify different types of filter log entries at a glance. Colour coding only applies to the live web display, and not to syslogs, etc.
 

Log format

The contents of the log entry depend on the protocol as follows.
 
Log formats
Fragments filter-name: Frag MAC proto-name(proto-num )/id@offset interface/IP-interface/IPaction
TCP filter-name: MAC TCP(6) interface/IP/ port-interface/IP/portflag saction
UDP filter-name: MAC UDP(17) interface/ IP/port-interface/IP/port action
ICMP filter-name: MAC ICMP(1) interface/IP/ type-name(type:code)-interface/IP/id action
Other filter-name: MAC proto-name(proto-num) interface/IP-interface/IP action
Big sessions End filter-name: proto-name( proto-num) interface/IP/port-interface/ IP/port forward/reverse

The meaning of these various fields are as follows. In all cases the source then the target interface/IP are shown.
 
filter-name The name of the filter, or Default for the default filter rule
MAC
 The source MAC address of the packet (0 if not known)
proto-name The name of the protocol, e.g. TCP, GRE, etc. There are over 100 named IP protocols
proto-num The protocol number, e.g. 6 for TCP, 17 for UDP, 1 for ICMP
interface The name of the interface, e.g. WAN, LAN, Serial, etc. The FireBrick's name is used for the FireBrick
IP The IP address, e.g. 1.2.3.4 or 001.002.003.004 if padded formatting has been configured
port The port number for UDP or TCP, e.g. 1234 or 1,234 if comma formatting configured
id@offset The IP packet ID and fragment offset
type-name The ICMP packet type, e.g. ECHO
type:code The ICMP type number and code number.
id The ICMP id word
flags TCP flags for S=SYN, A=ACK, R=RST, F=FIN which identify the type of TCP packet
action The action, Drop, Allow, Reject, Bounce, matching the colour coding
forward/reverse Total bytes sent in each direction on a session (forward is direction of first packet). If this exceeds
4.2 billion (32 bit wrap around) then it will be incorrect.