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.

OPT (020405B40402080A05E3F3C40000000001030300)

The items are explained in sequence:

More interesting files, such as multicast-addresses, can be found in http://www.iana.org/protocols/.

Issues with netfilter log format

Protocol Header Information

IP Header Format as defined in RFC-791:

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.

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				-	-	-	-									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):

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.

You can found useful information about cancer symptoms on the silcaat.com

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:
   “INCOMPLETE=0050445ACAFEAFFEEFFAEFAC“.
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.

Efficiency Issues

1. The worst case netfilter log line would easily exceed 400 chars.
2. The sheer length of the log lines typically causes wrapping over 2 or 3 lines on a 100 column xterm. This makes it extremely difficult to discriminate log records and to find individual items.
3. The LABEL=value format with multi char labels is approximately double the size of what it needs to be.
4. Interpreting flag bits and then printing them separately is approximately 10% as efficient as just printing the byte or word.
5. Mapping protocol numbers to names does not belong into the kernel.

Parsing Issues

1. Netfilter logs need a unique identifying mark. Recognition of netfilter logs is currently based on the hope that no other subsystem generates the fields we are using for identification.
2. Currently, the arbitrary nature of the user prefix makes it impossible to guarantee recognition of the start of the log record.
3. The user prefix needs to be separated from the next field by a space. It serves no conceivable purpose to have it joined up with the “IN=” field.
4. Simple extractor commands like the one below are defeated by the variable number of fields.
   awk '/DPT=111 /{printf("%s %s\n", $10, $15)} logfile'
5. The kernel code should not be burdened with providing a user interface by interpreting flags, protocol numbers and sub-fields.
6. Header lengths need to be logged. Since header-option logging is an iptables option there is no way of telling if the header really did not have any options or if they were just not logged.
7. The end of a log line needs to be reliably detectable by an unique field that is guaranteed to be present in all records. Relying on the EOL is unreliable because “newline” chars do occur in mid record if logging on the console and they can also be introduced by cut-n-paste operations.

Proposal for an alternative log format

Actually, there probably should be two log formats:

1. ipchains compatible, so existing applications can continue to be used.
2. a native format that is easy to read for a moderately experienced sysop and also parsable without resorting to unreasonable measures.

This format (with all options set) aims to make logfilter output consistent, cuts out some expansions, adds header-length (HLEN) fields and has a terminating mark “#”.

NF: USERPREFIX=userprefix IN=eth1 OUT= MAC=00808c1e1260,001076002fc2,0800 SRC=211.251.142.65 DST=203.164.4.223 LEN=100 TOS=0x00 TTL=44 ID=31526 FLAGS=0x4000 HLEN=60 OPT=072728CBA404DFCBA40253CBA4032ECBA403A2CBA4033ECBA402C1180746EA18074C52892734A200 PROTO=6 SPT=4515 DPT=111 SEQ=1168094040 ACK=0 WINDOW=32120 FLAGS=0x003 URGP=0 HLEN=40 OPT=020405B40402080A05E3F3C40000000001030300 #

We can already drop existing options (–log-ip-options, –log-tcp-sequence, –log-tcp-options) but the labels need to be kept so the number of fields remains constant. In most cases we could also drop the “MAC=..” (keep the label). These measures reduce the log to a more managable size:

NF: USERPREFIX=userprefix IN=eth1 OUT= MAC SRC=211.251.142.65 DST=203.164.4.223 LEN=100 TOS=0x00 TTL=44 ID=31526 FLAGS=0x4000 HLEN=60 OPT PROTO=6 SPT=4515 DPT=111 SEQ ACK WINDOW=32120 FLAGS=0x003 URGP HLEN=40 OPT #

Slightly re-ordering and shortening labels to single chars, but keeping labels for empty fields and reverting to the well known IP:PORT notation:

NF: U=userprefix 211.251.142.65:4515 203.164.4.223:111 I=eth1 O M L=100 S=0x00 T=44 I=31526 F=0x4000 H=60 P=6 S A W=32120 F=0x003 U H=40 O #

Other remedies

Harald Welte has written a ULOG module which provides and interface for a user-space daemon. This facility might allow a user-space plugin to produce customized output. It also won’t have to go through the old, inefficient syslog mechanism.

Unfortunately ULOG is not part of the kernel distribution yet. But it is available from http://gnumonks.org/projects/ for those who are willing and able to patch the kernel.

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:

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:

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.

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):

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):

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.

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.

ipchains firewall (minimal survival rules):

No time to do it properly?  Want to get on-line fast?  Here is a minimal ipchains rule-set for Linux kernels 2.2.x.   But don’t trust me!  Once you have it installed, test it here.  At the time of writing the latest kernel was 2.2.16, the information provided here has been tested with this kernel.The intention of providing this rule-set is to allow you to get on-line quickly while providing you with basic security until you have had time to implement something better.

No attempt has been made to optimize the rule-set.  It is quite conceiveable that you can re-order the rules or even reduce the number of rules – feel free to do that if you want to.  However, ipchains are quite efficient.  Each rule only takes a few micro seconds to traverse, so there is not much to be gained unless you have lots of rules, e.g. hundreds.

I am planning on putting a more elaborate ruleset here (the one I use on my own firewall) once I get around to cleaning it up.   

Stateful Firewalls:

A more secure solution can be provided by a stateful firewall. Such a firewall knows about many different protocols and it can look at the context of each packet and then filter according to that.Linux kernels 2.4.x have Netfilter which allows you to implement a stateful firewall.

A commercial, stateful firewall with an usable, free, limited edition is the Gnatbox.

A proxy server does essentially the same thing as a stateful firewall for the protocol it is designed for, but the design motivation for a proxy server may not be security. It could be performance (squid) or to block obnoxious material (junkbuster). “Socks” is a proxy server designed as a security measure; I found it to be unsatisfactory on my system, but YMMV.

Layered security:

It is common knowledge that several layers of security are better than one.  What sometimes is not so clear is that more of the same is not necessarily better, e.g. two identical firewalls are not much more secure than a single firewall.  The basic idea of multiple layers is to have something like this:

1st layer:	Packet filtering firewall.  Non essential services removed.
2nd layer:	Logging to a separate host or a printer (hardcopy).  Intrusion detection installed.
3rd layer:	Where appropriate, servers installed in a chrooted “jail”.  Telnet, ftp and other programs which transmit passwords in clear text eliminated or tunneled through a secure channel.
4th layer:	Security conscious installation of client software, e.g. no suid-root clients.

Do I use all of those?  No, only about two thirds of this.  It is up to you to judge how much security is appropriate and if the effort and cost is worth the benefit for you.

Firewall Related Links

Cut-down versions of Linux.  Optimized as routers and/or firewalls:

Floppy Firewall

Tom’s rtbt not a firewall, but a single floppy Linux system, links to similar systems.

Hardening system for various Linux distros:

Bastille Linux

A commercial firewall, and a limited but still useful, no-cost version:

GNAT Box – The Simple Powerful and Affordable Firewall

Port Scanning Services:

Norton Online Systems (good)

Intrusion Detection:

Tripwire

Snort!

Secure Servers and Clients:

Get rid of telnet and ftp.  Use ssh, scp, rsync instead.

OpenSSH Excellent implementation of ssh1 and ssh2.

rsync can be used with ssh.  It is a really useful utility to keep directories on a remote hosts in synch with the local version, or vice versa.  Also uses conpression and does incremental updates.  Hint: explore ssh-agent (part of ssh).

Other useful information:

Allwhois.com – Search any domain name in the world!

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

REJECT

means that for every packet received an ICMP port unreachable packet is sent to the source address.  Of course this tells the remote host that your system is up and running and that you are running a firewall.For the identd service (port 113) read the identd section further down.

Example: Port 23 is set to REJECT:

08:29:33.908826 reddwarf.xix.com.2876 > megahard.xix.com.23: S

611071769:611071769(0) win 32120

<mss 1460,sackOK,timestamp 8136624[|tcp]> (DF) [tos 0x10]

08:29:33.908826 megahard.xix.com > reddwarf.xix.com:

icmp: megahard.xix.com tcp port 23 unreachable [tos 0xd0]

The response to the syn-packet (S) is an ICMP port “unreachable”;.

DENY

means the packet is discarded, dropped to the floor, assigned to oblivion.  No reply packet of any kind is sent.  (In the new iptables for Linux 2.4, this is now called DROP, which is clearer than DENY).If you set a rule which matches a particular source address and a rule-target of DENY, then your computer may as well be turned off as far as that source address is concerned.  However, if you DENY some port ranges, say ports below 1024, and allow others, then it is also obvious that you are running a firewall.

For the identd service (port 113) read the identd section further down.

Example: Port 24 is set to DENY:

08:29:36.138037 reddwarf.xix.com.2877 > megahard.xix.com.24: S

621695306:621695306(0) win 32120

<mss 1460,sackOK,timestamp 8136847[|tcp]> (DF) [tos 0x10]

There is no response to the syn-packet (S) and reddwarf keeps trying a few more times.

ACCEPT  (or no firewall)

There are two cases here.  Either there is a service listening on that port or not.Example: Port 12345 with no service listening:

08:43:11.386320 reddwarf.xix.com.1302 > megahard.xix.com.12345: S

1961263534:1961263534(0) win 32120

<mss 1460,sackOK,timestamp 7858375[|tcp]> (DF) [tos 0x10]

08:43:11.386320 megahard.xix.com.12345 > reddwarf.xix.com.1302: R

0:0(0) ack 1961263535 win 0 [tos 0x10]

The response to the syn-packet (S) is a connection reset (R).  This is clearly different from what you get from an ipchains firewall.

Example: Port 22 with sshd listening:

08:41:27.840998 reddwarf.xix.com.2878 > megahard.xix.com.22: S

1377668429:1377668429(0) win 32120

<mss 1460,sackOK,timestamp 8208017[|tcp]> (DF)

08:41:27.840998 megahard.xix.com.22 > reddwarf.xix.com.2878: S

1362603816:1362603816(0) ack 1377668430 win 32120

<mss 1460,sackOK,timestamp 62682656[|tcp]> (DF)

08:41:27.840998 reddwarf.xix.com.2878 > megahard.xix.com.22: .

ack 1 win 32120 <nop,nop,timestamp 8208017 62682656> (DF)

A successfully established TCP connection.  The hosts have exchanged and acknowleged their respective syn-packets (S).

How does nmap see these ports?

As before, port 21 is not used (it has nothing listening on it).

Port 22 is open with ssh listening.

Ports 23 and 24 have these ipchains rules:

megahard:# ipchains -I input -i eth0 -p tcp --dport 23 -j REJECT

megahard:# ipchains -I input -i eth0 -p tcp --dport 24 -j DENYreddwarf:# nmap -sT -p 21-24 megahard

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)

Interesting ports on megahard (192.168.1.1):

Port    State       Protocol  Service

22      open        tcp        ssh

23      filtered    tcp        telnet

24      filtered    tcp        priv-mail

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

nmap has no trouble recognising both firewalled ports as filtered!

Presumably, it classes the DENYed port as filtered because there was a response from other ports at the same IP address.

Which one is better?

LAN:

REJECT is appropriate for UDP packets you don’t want to accept, it causes an ICMP port unreachable reply.  The correct response to unwanted TCP packets is a reset, unfortunately ipchains is not capable of sending a TCP reset.   Sending port unreachable ICMP messages in response to a TCP packet (as REJECT does) is useless and is disregarded by many protocol stacks.  A viable option is to use DENY, which sends no reply.  Alternatively you can use a package such as return-rst in conjunction with ipchains to produce the correct response.

Internet:

I believe in making it unpleasant for people who have no business connecting to my system, so those rules use DENY.   I have also observed that once I changed most of my ipchains rules from REJECT to DENY,  the number of connection attempts has dropped to a fraction of what it used to be.

More recently (December 2000), I have changed back to REJECT for UDP and I use return-rst for TCP.   For other protocols I use DENY.   Within a few days, the number of firewall hits has increased by at least a factor of two!  I’ll keep watching this for a while.

identd / authd:

Some servers will attempt to establish your identity before proceeding with your connection.  If you don’t run an identd or authd, a TCP reset is normally returned and everything is fine.If you firewall port 113 with REJECT or DENY,  you are likely to experience inconvenient delays.  My recommendation is therefore to leave that port open and to make sure you don’t run a server there.  Or if you do run an identd, make sure you picked an up-to-date one with a good reputation.

Revealing the existence of a firewall?

I have heard the argument that DENY gives away the presence of a firewall and REJECT does not.  The above examples prove this argument to be nonsense. It is possible to make your system look like it has not got a firewall, at least on first inspection.   Use REJECT for all UDP, and for TCP, implement a means of sending reset packets, for example with return-rst.  Other protocols should be DENYed.