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 http://www.iana.org/protocols/.
Protocol Header Information
IP Header Format as defined in RFC-791:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | ||
| IP Version | Hdr.Length | TOS / DS,ECN | Total Length | ||||||||||||||||||||||||||||||
| Identification | – | DF | MF | Fragment Offset | |||||||||||||||||||||||||||||
| Time To Live | Protocol Number | Header Checksum | |||||||||||||||||||||||||||||||
| 32 bit Source Address | |||||||||||||||||||||||||||||||||
| 32 bit Destination Address | |||||||||||||||||||||||||||||||||
| Options (0 to 10 Words of 32 Bits) | |||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
The header of an IP packet consists of 5 or more words of 32 bits (4 bytes) each. The minimum header length (no options) is therefore 20 bytes. The Version field for the shown type of packet is 4 = IPv4 (Internet Protocol version 4). The header Length field is the header length in 32bit words, this would be 5 without options, and at most 15 with options. The Total Length is in bytes and includes the header. Data length can then be calculated from the supplied values. TOS / DS / ECN: This field has had an unstable history. This is briefly explained in RFC2481, section 19 (near the end).Many sites are starting to implement Differentiated Services DS [RFC2474] in their routers. DS uses code-points which are stored in bits 0 to 5 of the old TOS field. The content and meaning of this field can change at network boundaries.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |
| TOS | Precedence | Type | – | |||||
| DS,ECN | DS Codepoint | ECT | CE | |||||
If the host is ECN [RFC2481] capable and the payload is a TCP packet, then up to two flag bits will be needed in the old TOS field. Bit 6 becomes the ECT (ECN-capable Transport) flag, and Bit 7 becomes the CE (Congestion Experienced) flag.IP datagrams can be fragmented if the link layer cannot fit it into a single link layer data unit. The fragment offset is specified in units of 8-bytes, thus allowing the available 13 bits to cover the necessary values for up to 64K of data.
IP packets usually carry a higher level protocol such as TCP. In the case of TCP, the PROTO field would be set to 6 and the TCP Protocol Data Unit (PDU) is carried in the IP Payload field of the packet. See below.
TCP Header Format (as defined in RFC-793):
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Source Port | Destination Port | ||||||||||||||||||||||||||||||
| Sequence Number | |||||||||||||||||||||||||||||||
| Acknowledgement Number | |||||||||||||||||||||||||||||||
| Data Offset |
– | – | – | – | CWR | ECNE | URG | ACK | PSH | RST | SYN | FIN | Window | ||||||||||||||||||
| Checksum | Urgent Pointer | ||||||||||||||||||||||||||||||
| Options (0 to 10 Words of 32 Bits) | |||||||||||||||||||||||||||||||
| TCP Payload | |||||||||||||||||||||||||||||||
The header of a TCP packet consists of 5 or more words of 32 bits (4 bytes) each. The minimum header length (no options) is therefore 20 bytes. The Data Offset field is the header length in 32bit words, this would be 5 without options, and at most 15 with options.Explicit Congestion Notification (ECN) [RFC2481] adds 2 new flags to the TCP header: Congestion Window Reduced (CWR) and ECN-Echo (ECNE). ECN also requires 1 or 2 additional flags in the IP header.
Commonly, the TCP header will carry options related to enhancements of the TCP protocol. Important options are Window Scaling, Selective Acknowledgement (SACK) [RFC2018, RFC2883] and Explicit Congestion Notification (ECN) [RFC2481].
TCP data payload length is the IP payload length minus the TCP header length.
TCP packets usually carry an application level data stream, f.e. HTTP, FTP, Telnet, SSH, etc.
UDP Header format (as defined in RFC-768):
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Source Port | Destination Port | ||||||||||||||||||||||||||||||
| Total Length | Checksum (optional) | ||||||||||||||||||||||||||||||
| UDP Payload | |||||||||||||||||||||||||||||||
The header of a UDP packet consists of 2 words of 32 bits (4 bytes) each. The header length is therefore always 8 bytes. The Total Length field includes the UDP header and is measured in bytes.
UDP packets usually carry an application level datagram as their payload, f.e. DNS, NTP, NFS, etc.