Re: iptables STILL incorrectly using TCP packet contents without checking header!

[Amin Azez <azez@ufomechanic.net>]

Simon Kirby wrote:
> If checksumming were implemented in this case and the rule no longer
> matched a corrupted packet, the packet would still be forwarded. 
> However, the end point should just discard it.  I don't think this
> will introduce any new problems except possibly for the ability to
> fling loads of corrupted packets (DoS) past firewalls if TCP is
> blocked with something like:
> 
> 	iptables -A FORWARD -p tcp --dport 0:65535 -j REJECT
> 
> This is probably a rare case, but probably worth noting.
> 
> Is there anything else?

Possibly this discussion is about to get philosophical:

One mans corrupt packet is another mans disguise.

Off the top of my head, propogating corrupt packets could perhaps be 
used to subvert the firewall with the help of a co-operating box on the 
inside that will accept and perhaps fixup the corrupt packets, or at 
least do something with it.

We know that if an internal box has been "taken over" that all bets are 
off anyway, but that is no excuse for the firewall to fail in its duty. 
Various means including TCP/IP encapsulated in DNS requests can be used 
to subvert firewalls but at least they show up and can be handled be 
iptables or various other mechanisms.

Is this a "new problem"? I don't know, but it could be a problem.

Perhaps there is no practical difference between "corrupted packet" and 
"unknown protocol" ?

IMHO corrupt packets should be dropped and not forwarded, and possibly 
people want a similar rule for unknown protocols?

I much perfer your previous suggestion:
	iptables -A FORWARD -m checksum ! --checksum ip -J DROP
	iptables -A FORWARD -p tcp -m checksum ! --checksum tcp -J DROP

and I really think they ought to be the first rules in the FORWARD chain 
by default.

Amin