Netfilter Log Format

Here is a quick reference for the format used by the netfilter log messages.   This is all derived from the source of the netfilter kernel modules (Linux kernel 2.4.2).

Below is a hypothetical log message generated by netfilter. It is based on a real log entry but I have added all possible IP and TCP flags as well as a fragment offset for illustrative purposes.

Apr 16 00:30:45 megahard kernel:
NF: D(I,Priv) IN=eth1
TOS=0x00 PREC=0x00 TTL=44 ID=31526 CE DF MF FRAG=179
OPT (072728CBA404DFCBA40253CBA4032ECBA403A2CBA4033ECBA40
PROTO=TCP SPT=4515 DPT=111 SEQ=1168094040 ACK=0

OPT (020405B40402080A05E3F3C40000000001030300)

Continue reading →

Netfilter Log Format Issues


  1. Netfilter logs are intuitive and easy to read by the occasional, non-expert admin.
  2. They provide much more information than f.e. ipchains, in particular about the transport protocol.
  3. Show the header of messages returned inside an ICMP packet.

Consistency Issues

  1. Most items in the log use the LABEL=value format, but:
    flags appear on their own,
    options use “OPT (abc..)“, and
    incomplete is flagged like this: “INCOMPLETE [12 bytes]“!
    The latter would also be much more useful if it showed the data:
  2. The TOS field is ripped apart into “TOS” and “PREC”. This is particularly bad because TOS is increasingly being replaced by DS and ECN.
  3. The two MAC addresses and the type-code are thrown together into one 14 byte sequence.
  4. Recursive headers are enclosed in [..] but the [..] are also used for other purposes including inside a recursive header.
  5. Having a variable number of fields makes it impossible to quickly extract specific information. F.e. the following will fail miserably if the number of IP options varies:
    awk '/DPT=53 /{printf("%s %s\n", $10, $15)} logfile'
  6. The user prefix ought not to allow white space. Having a variable number of spaces (from different prefixes) makes it impossible to quickly extract specific information, see previous point.

Continue reading →

ipchains Log Format

Here is a quick reference for the format used by the ipchains log messages. This is mostly taken from the ipchains-HOWTO

A typical log message generated by ipchains:

Jun 16 08:00:38 megahard kernel: Packet log: forward DENY
eth1 PROTO=17 a.b.c.d:234 w.x.y.z:34567 L=78 S=0x00 I=13413
F=0x0000 T=112 (#16)

The leading part is self explanatory. The remaining items are explained in sequence here:

forward Name of the chain which was traversed by the packet
DENY action taken by ipchains
eth1 interface the packet was passing through
PROTO=17 Protocol number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers
a.b.c.d source IP address
234 source port (TCP and UDP) or the ICMP type. A list of port numbers is in your /etc/services. A complete list is in the file port-numbers
w.x.y.z destination IP address
34567 destination port (TCP and UDP) or the ICMP code. A list of ICMP types and codes is in the file icmp-parameters
L=78 total Length of packet in bytes
S=0x00 type of Service (TOS), only 4 bits used these days, not important for firewall purposes
I=13413 IP-ID, increments with each packet sent
F=0x0000 Flags (3 bits) and Fragment offset (13 bits)
T=112 Time to live (TTL) or hops remaining before packet is dropped
(#16) rule number in the chain which matched the packet and caused the log

More interesting files, such as multicast-addresses, can be found in

Continue reading →

Linux Firewalls

Packet filtering firewall:

Linux ipchains implement a packet filtering firewall and can be considered medium security if implemented properly.  A packet filtering firewall looks at each packet individually, it does not (can not) consider any previous packets which may be part of a multiple packet transaction.  In other words, a packet filtering firewall is stateless.

Continue reading →

What is the difference between REJECT and DENY?

With ipchains you can ACCEPT, REJECT or DENY a packet.  What ACCEPT does is self-explainatory, but nearly everybody  asks what the difference between REJECT and DENY is and which one is better.  And how does nmap see the ports?

Below is my attempt at explaining the differences.  The example transactions were captured with tcpdump.

Continue reading →