[PATCH] netfilter-0.1.16

[Jozsef Kadlecsik]

Hello,

On Tue, 18 Jan 2000, Andi Kleen wrote:

> > The attached patch against netfilter-0.1.16 adds the following new
> > features:
> > 
> > 1. REJECT: different reject packets can be selected:
> > 
> > 	- ICMP net, host, proto or port unreachable 
> > 	  (just for the sake of completeness :-)
> 
> That looks good.
> 
> > 	- TCP RST for TCP
> 
> Ugh very bad. Forging TCP. Destroying TCP's robustness against routing
> topology changes. 

I don't really understand your comment. The task is to reject a TCP
connection on a firewall, which can be done by sending back either an ICMP
error message or a TCP RST segment.

There are scenarios, in which cases there is even no other way to tell 
the other side to give up than to send back TCP RST. Let's assume a client
behind a (stupidly) configured firewall, which doesn't let through ICMP
error messages.  Then only a TCP RST segment could tell the client to stop
trying connecting.

It is not uncommon: for example Darren Reed's ip_filter
(http://coombs.anu.edu.au/~avalon/ip-filter.html) has this feature. 
The sifi firewall for Linux (http://www.ifi.unizh.ch/ikm/SINUS/firewall/)
has ditto. 

> >    After the server sent SYN-ACK, an ACK packet coming from the client 
> >    can be faked, thus protecting the server against SYN flood attempts.
> 
> Erm. That is totally bogus. What are you trying to archive?

To finish the three-way handshake of the TCP connection on behalf of the
client, thus protecting the backlog queue on the server.

This is the same as the SYNDefender Gateway in Checkpoint Firewall-1
(http://www.checkpoint.com/products/firewall-1/syndefender.html).

The SYNDefender Relay mode, which is IMHO a little bit more elegant
solution, unfortunately needs more work to implement. :-)

> You also deleted iptables.c in your patch -- Rusty won't like that ;)

It is renamed only to ip_tables.c! :-)

> Your generated changes are ugly. It would be much better to use a special
> sbk->mark value for this purpose. 
> 
> To avoid the icmp.c changes better use a special ICMP code (e.g.
> ICMP_DEST_UNREACH | NETFILTER_GENERATED) and check and remove that in an
> output filter.

Yes, the kernel patch is ugly. I didn't really see other way
to pass a flag to ip_build_xmit for the new skb to be generated with 
a defined nfcache value than to add a new argument to the function. 
The new argument can be avoided at icmp_send, icmp_reply and
ip_send_reply using skb->nfmark for example, but I don't see how does 
one propagate its value to ip_build_xmit (except using a new argument).

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary