====== Firewall Log ======

The firewall log gives you an opportunity to see what packets have been treated by the firewall and what actions have been taken.

===== Activate =====
:!: The firewall log is by default turned off to ensure maximal throughput. You must enable firewall log on the [[log configuration page]] to be able to use it.

===== Filter =====
The **Display Filter** on the Firewall Log page is for //post-grab//-filtering - it controls display of already recorded data.

To configure what packets to log in the firewall log use the [[Log Configuration page]].

Thus for example if you have selected "Firewall Log: Show rejected packets" then no ACCEPT packets will be logged. Thus enabling ACCEPT on the Display Filter will not show any such packets as they never become logged.

===== Export =====
You can export the firewall log to various receivers (syslog server, SNMP server, e-mail, USB, etc) on the [[log configuration page]].\\
:!: Easiest way of copying the firewall log to e.g. an e-mail is using Ctrl+A, Ctrl+C

{{ :web_gui:firewall_log_page.png?185|Firewall Log page in rel 5.30}}

===== Interpret =====
The firewall log information is for advanced users only. Contrary to common belief the firewall does **not** need to be monitored to see attempted attacks – it performs its task just as well unmonitored. Also, it is of little use trying to see where attacks came from, as most hackers alter their IP addresses.

Different information is given depending on the packet type, but some attributes are always logged; time when the packet was seen, interface the packet was seen on, direction of the packet, the packet's size in bytes and the protocol type.

In most cases the source and destination address is also logged.

Finally the action taken is logged, specified as a main action; accept, deny, drop or error followed by a more specific reason, e.g. "deny default rule".

This action is also broken down, showing in detail what decisions that were taken by the firewall. This includes which supervisor rule, flow (if any) and user rule (if any) that were matched. For each rule or flow information about the associated action or state is also logged.

==== Example - TCP connection establishment: ====
1) 0d 22:28:14:et2i 192.168.0.2 > 1.2.3.4 (44) tcp: S 3263 > 80 (0) - ACCEPT rule - s(0)accept u(2)accept

This packet was received on et2 (the " i " after the names stands for "incoming") and is an IP packet from 192.168.0.2 to 1.2.3.4 with a length of 44 bytes. The IP packet contains a TCP SYN-segment (the " S " after "tcp:" is the SYN TCP-flag) from port 3263 to port 80 with a payload size of 0 bytes. The final action for the packet was an " ACCEPT rule " which means that firewall rules made the firewall accept the packet. " s(0)accept u(2)accept " specifies that it was the first super rule and the third user rule that were the ones that accepted the packet.

2) 0d 22:28:14:et1o 192.168.0.2 > 1.2.3.4 (44) tcp: S 3263 > 80 (0) - ACCEPT rule - u(1)modify f(c94954)init/syn-rcvd s(0)accept - MODIFY saddr 192.168.5.66 sport 60001

The first log entry (1) is immediately followed by the same packet, but this time it is transmitted on another interface (" et1 ", " o " as in "outgoing"). ACCEPT rule - u(1)modify f(c94954)init/syn-rcvd s(0)accept means the second user rule created a flow c94954 that moved from its init state to syn state in the stateful inspection. Then the first super rule also accepted the packet. MODIFY saddr 192.168.5.66 sport 60001 indicates the packet has also been modified (NAT:ed), source address and port has been changed.

3) 0d 22:28:14:et1i 1.2.3.4 > 192.168.5.66 (44) tcp: AS 80 > 60001 (0) - ACCEPT flow - s(1)accept f(c949a4)wait-syn-ack/syn-ack-rcvd - MODIFY daddr 192.168.0.2 dport 3263

This packet is the response to that in (1) and (2). Now both the S (SYN) and A (ACK) TCP-flags are set. It first matches supervisor rule 1 and then flow c949a4 which makes the final decision for the packet, resulting in a "ACCEPT flow" final action. wait-syn-ack/syn-ack-rcvd means the stateful inspection moved from wait-syn-ack state to syn-ack-rcvd state.

4) 0d 22:28:14:et2o 1.2.3.4 > 192.168.0.2 (44) tcp: AS 80 > 3263 (0) - ACCEPT rule - u(0)accept s(0)accept

This is the same packet as in (3) but forwarded to the et2 interface.

5) 0d 22:28:14:et2i 192.168.0.2 > 1.2.3.4 (40) tcp: A 3263 > 80 (0) - ACCEPT rule - s(0)accept u(2)accept

This packet is the last in the TCP "3-way handshake" which completes the connection establishment. Now only the A (ACK) TCP-flag is set.

6) 0d 22:28:14:et1o 192.168.0.2 > 1.2.3.4 (40) tcp: A 3263 > 80 (0) - ACCEPT rule - f(c94954)wait-ack/open s(0)accept - MODIFY saddr 192.168.5.66 sport 60001

This is the same packet as in (5), but forwarded to the et1 interface. It matches the same flow as the packet in (2) and the flow's state changes from "wait-ack" to "open".

==== Example - DENY: ====
APR 25 11:36:03:et2i 192.168.0.2 > 1.2.3.4 (44) S 3263 > 1243 (0) - DENY default rule - s(1)accept u(-1)deny

This packet attempted to enter through port 1243. u(-1)deny indicates there was no user rule allowing it through the firewall, therefore the packet was denied.

If you really want to allow the packet to pass through the firewall you have to open port 1243 manually. (However, as just port 1243 is used by the SubSeven Trojan horse, you are not recommended to do so.)

0d 00:40:43:linei 212.159.10.2 > 1.2.3.4 (40) tcp: A 110 > 60034 (0) - DENY flow - s(1)accept f(cb0754)wait-syn-ack/illegal - MODIFY daddr 192.168.20.31 dport 3434

DENY flow indicates that this packet was stopped by the flow stateful inspection. wait-syn-ack/illegal indicates that the stateful inspection was in the wait-syn-ack state, expecting a SA (syn-ack) packet. However, the received packet was a tcp: A (ack) packet. Therefore the stateful inspection stopped the packet, and the flow entered the illegal state.

If you really want to allow the packet to pass, you need to uncheck Enable strict TCP inspection in General settings of the current Security profile .

Example - fragments:

0d 21:17:49:et2i 192.168.0.11 > 192.168.0.1 #64018 (1500+@0) icmp: 8/0 echo req - ACCEPT rule - s(0)accept u(6)accept

#64018 (1500+@0) means the received packet is a 1500-byte fragment at offset 0 (first fragment), with fragment ID 64018. The "+" indicates there are more fragments to come.

0d 21:17:49:et2i 192.168.0.11 > 192.168.0.1 #64018 (548-@1480) icmp: (fragment) - ACCEPT rule - s(0)accept u(6)accept

This is the second fragment in the transmission. It is a 548-byte fragment, at offset 1480. The "-" indicates this is the last fragment.

0d 21:08:08:et2i 192.168.0.11 > 192.168.0.1 #56080 (68-@2960) icmp: (fragment) - DROP reversely ordered frag -

Reversely ordered fragments (when fragment transmission does not start with the 0-offset fragment but some other) are not supported by Internet Gate as they are not possible to NAT correctly as the header information needed to NAT is only present in that first fragment.

==== Commonly attacked destination ports ====
By examining the attempted destination port number, you can recognise some common attacks attempted against your computer:

^ destination port ^ ^
| icmp: 8/0 echo req	| Most common attacks start with a simple ping to detect if there is any computer at the attacked IP address. Other icmp packet types are also commonly used to determine computer presence. |
| 11	| Sysstat vulnerability |
| 79	| Finger vulnerability |
| 137	| NetBIOS – this is perfectly normal traffic generated by Windows machines that still should be stopped from entering other subnets. |
| 139, 445	| NetBIOS file sharing vulnerability. |
| 515	| lp printer vulnerability. |
| 600, 1524	| PcServer backdoor. |
| 1243, 6711, 6776, 27374	| SubSeven Trojan horse. |
| 5632	| PcAnywhere remote control program. |
| 30100	| NetSphere Trojan horse. |
| 31337	| Back Orifice Trojan horse. |
| 31789	| Hack-a-tack Trojan horse. |
| 555, 3129, 6670, 6969, 21544, 12345, 23456, 50505	| Other Trojan horses. |

==== General log entry format ====
Each log entry follows the same format ('' denotes variables, [] optional information {|} "selective" information, i.e. "one of".):

'time' : 'interface''dir' 'proto info' - 'action' [ - 'match info'] [ - 'sub action']

^ Overview of log entry components ^^
| 'time'	| The time when the packet was logged expressed in days, hours, minutes and seconds since power on (uptime), e.g. "01d 12:34:56" means 1 day 12 hours 34 minutes 56 seconds since power on.\\ If the SNTP client is enabled, time will be expressed in true date and time, e.g. "APR 25 11:36:03" |
| 'interface'	| The name of the interface the packet was seen on, e.g. "et1" |
| 'dir'	| Direction of the packet; i = incoming, o = outgoing, e.g "line i ". |
|'proto info'	| Protocol information - see table below. |
| 'action'	| Final action taken by the firewall for the packet. Composed of a general action and, in some cases, a specific reason for why the action was taken, e.g. "DENY default rule". |
| 'match info' (optional)	| What objects (rule, flow) in the firewall matched the packet? See below for more information. |
| 'sub action' (optional)	| Any supplementary action taken for the packet. Sub action arguments are also logged, e.g. "MODIFY saddr 1.2.3.4" for (source) NAT:ed packets. |

==== Protocol information format ====
=== IP packets: ===
'src ip addr' > 'dst ip addr' [#'id'] ('length'['more frags'@'offset']) 'proto': 'proto info'

^ Protocol information - IP ^^
| 'src ip addr'	| Source IP address of packet, e.g. 192.168.0.2. |
| 'dst ip addr'	| Destination IP address of packet. |
| 'id' (optional; fragments only)	| IP datagram identification number (decimal), e.g. 34523. |
| 'length' (non fragments)	| IP packet length (decimal). And offset (both decimal), e.g. 150 or 540-@1460 |
|'more frags'@'offset' (fragments)	| Fragment information; 'more frags' indicates whether this is the last fragment ("-") or not ("+"). |
| 'proto'	| Procol type. Expressed as number (decimal) or name (for common protocols), e.g. 103 or "udp" |
| 'proto info'	| Varies with protocol - see below. |

=== ICMP packets: ===
'type'/'code' 'type name'

=== TCP segments: ===
'tcp flags' 'src port' > 'dst port' ('tcp length')

=== UDP datagrams: ===
'src port' > 'dst port' ('udp length')

=== Other ===
Most other protocols are just logged as "(unhandled)"

^ Protocol information - TCP/UDP ^^
| 'tcp flags' (TCP only)	| TCP flags; U = URG (urgent), A = ACK (acknowledge), P = PSH (push), R = RST (reset), S = SYN (synchronize), F = FIN ("finish"), e.g. "SA" |
| 'sport'	| Source port (decimal), e.g. "2765". |
| 'dport'	| Destination port (decimal), e.g. "80". |
| 'tcp length', 'udp length'	| Length of payload (decimal), .e.g. "700". |

=== ARP packets: ===
'arp op' 'src ip addr' 'dst ip addr'

=== Ethernet frames (undecoded): ===
'src ether addr' > 'dst ether addr' ('length') 'type'

^ Protocol information - Ethernet ^^
| 'src ether addr'	| Source address (colon separated hexadecimal format) |
| 'dst ether addr'	| Destination address. |
| 'length'	| Length of frame (decimal). |
| 'type'	| Type field (hexadecimal). |

==== Matching information format ====
Describes what objects, i.e. which rule (through its filter specification) or flow (through its attributes), that matched the packet. (See firewall rule [[firewall:syntax]] for more information about rules and flows.)

=== Incoming packets: ===
s('super rule id')'action' {f('flow id')'old state'/'new state' | u('user rule id')'action'}

=== Outgoing packets: ===
{f('flow id')'old state'/'new state' | u('user rule id')'action'} s('super rule id')'action'

^ Match information ^^
| 'super rule id'	| Supervisor rule id (decimal). Indicates which rule (0..n) that matched the packet. -1 indicates the "default rule", i.e. no rule matched. |
| 'user rule id' (optional; only if no flow matched.)	| User rule id (decimal). |
| 'action'	| The rule's associated action. |
| 'flow id' (optional; only if a matching flow existed.)	| Flow id (hexadecimal). Indicates which flow that matched the packet. |
| 'old state'	| Previous flow state (before the packet was inspected). |
| 'new state'	| New flow state (after the packet was inspected). |