Notes:

Iptables firewall rules.

- Testing: Linux Kernel 2.4.0-test1
	   Linux Kernel 2.4.0-test2
	   Linux Kernel 2.4.0-test3
	   Linux Kernel 2.4.0-test4

- Interesting new options:
   - --tcp-flags option, very useful
   - --tcp-options
   - --mac-source
   - --limit, very interesting option.
   - --*-owner variants, cool stuff.
   - --state, very useful.
   - Netfilter will apparently just drop packets with headers which are
     too small to read(according to the docs). Is this equivalent to the
     "....with short" rule in ipf? 
   - More notes on options below.
   - blah blah

- Need to watch for the following differences:
   - -i and -o options with the INPUT, OUTPUT and forward rules.
	- -i can only be used to describe incoming packets on the
	  interface.  Can't use OUTPUT with -i flag, be careful. Not
	  so terrible, so it shouldn't confuse us, right? ;)
   - -m limit/tos/etc, match extensions must be declared before they
       will work properly.
   - Masquerading is quite different. NAT is more flexible, better.
   - To get the effect of -t in ipchains we'll have to alter the
       mangle table, "-t mangle -j TOS --set-tos bleh".
   - -d in iptables cannot accept a destination port as in ipchains,
       use --dport.

Stuff:

1) This matches TCP SYN flag, to DROP a tcp packet headed to the external 
interface with only the SYN flag set:
[iptables -A INPUT -i eth0 -p tcp ! --tcp-flags SYN,RST,ACK  SYN -j ACCEPT]

  - Why not write an new chain to deal with tcp flags.
	- DROP packets with only the SYN packet set, but do look at the
	  other flags.
	- FIN/URG/PUSH(NMAP XMAS) is a bad thing, DROP and log it.
	- Xmas tree.
	- Xmas tree minus the PUSH flag.
	- Set limits to the amount of logging done per minute.
	- etc, etc...
	- I need aspirin...

2) TCP options.  Iptables' --tcp-options option requires a number to
represent the options.  Is this a useful option?

3) Accepting incoming packets destined for high ports.
[iptables -A INPUT -p tcp -s 0/0 -d 0/0 1023:65000 -j ACCEPT]

Mainly for ftp support or whatever.  The NAT implimentation that comes with
netfilter allows us to watch the state of a connection.  Also allows for ftp
proxy similar to what ipnat can do in BSD, so no need to worry
about passive/active ftp. Seems to work well.

4) Regarding chains CHECK_FLAGS and KEEP_STATE.
	- If KEEP_STATE is jumped to first, packets associated with a
	  connection are allowed through the firewall. Which means that if
	  some wierdo wants to send strange packets at me he could do so
	  by fooling iptables into thinking they are part of an
	  established connection.  Wouldn't be too difficult.
	- If CHECK_FLAGS is jumped to first we might be a bit safer, but
	  will very likely have to look at many more packets.  We
          already have to look at them twice since there is no way to
          LOG and DROP a packet in the same rule.
   - As it is at the moment, CHECK_FLAGS is jumped to in the
      EXTERNAL-input chain, which is the chain that controls input to the
      external interface, before KEEP_STATE. This provides a little more
      security and a little more overhead. Also notice that we're not
      jumping to CHECK_FLAGS to filter any outgoing packets, how rude of
      us ;p.

5) Still no ability to filter via ip options, bummer.
    - echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
    - echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route

* The rc.firewall.iptables script is an example for a network with
a single dual homed firewall. Our theories may differ, but my goal
was to deny as much traffic as possible coming into the network
without undermining the versatility of the network itself. This
is what alot of people want anyway.


Bugs:

 - REJECT, no worky in test1 kernel.
	- According to the netfilter mailing list, if the "iptables_nat"
	  module is loaded in the kernel, ICMP error messages cease.  In
	  this case, I compiled everything into the kernel, and I'm too
	  lazy to patch it :(.  Patch is available tho, no biggie.