REJECT patch

From kadlec@blackhole.kfki.hu Mon Sep 17 09:53:08 2001
Date: Wed, 2 Feb 2000 16:17:38 +0100 (CET)
From: Jozsef Kadlecsik 
To: netfilter@samba.anu.edu.au
Subject: [PATCH] REJECT patch 2. ver

Hello,

This is the second version of my REJECT patch. As it was suggested 
by Andi Kleen, I avoided to do the faked packets generation in the
IP stack, so the required patch against linux-2.3.40 is shrinked to

*** linux/net/netsyms.c.orig    Wed Jan 26 13:53:40 2000
--- linux/net/netsyms.c Wed Jan 26 14:21:09 2000
***************
*** 589,594 ****
--- 589,596 ----
  EXPORT_SYMBOL(nf_unregister_interest);
  EXPORT_SYMBOL(nf_hook_slow);
  EXPORT_SYMBOL(nf_hooks);
+ EXPORT_SYMBOL(ip_options_echo);
+ EXPORT_SYMBOL(ip_options_build);
  #endif
  
  EXPORT_SYMBOL(register_gifconf);

The new features, again:

1. REJECT: different reject packets can be selected:

	- ICMP net, host, proto or port unreachable
	- faked TCP RST for TCP
	- faked echo reply for echo request

Out of curiosity - using the patched netfilter as the packet generator -
I tested how different OSes (Linux, Solaris, Windows) react when receiving
different kind of reject packets. Then asked some of my friends with
access to machines with other OSes to run the tests, which were simply:

% telnet test.machine 500
...
% telnet test.machine 504

The configuration on the test machine was:

iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 500 -j REJECT --with net-unreach
iptables -A INPUT -p tcp --dport 501 -j REJECT --with host-unreach
iptables -A INPUT -p tcp --dport 502 -j REJECT --with proto-unreach
iptables -A INPUT -p tcp --dport 503 -j REJECT --with port-unreach
iptables -A INPUT -p tcp --dport 504 -j REJECT --with tcp-reset

The results of the telnet attempts can be summarized in the following
table:

Reject with	net unr.    host unr.    proto unr.    port unr.    TCP RST

Linux 2.x.x	abort 	    abort        abort         abort        abort 
FreeBSD 3.3	abort       abort        abort         abort        abort 
HP-UX 9.01	abort       abort        abort         abort        abort 
ULTRIX 4.3/4.4	abort 	    abort        abort         abort        abort 
Solaris 2.6/7	ignore      ignore       abort         abort        abort 
Windows 98/NT	ignore      ignore       abort         ignore       abort 
AIX 4.2/4.3	ignore      ignore       ignore        ignore       abort 
IRIX 6.2	ignore      ignore       ignore        ignore       abort 
OSF1 4.0	ignore      ignore       ignore        ignore       abort 

2. state: simple protection against SYN flooding

   After the server sent SYN-ACK, an ACK packet coming from the client 
   is faked, thus protecting the server against SYN flood attempts.

   As it was pointed out, it is a really *bad* practice with servers
   having modern stacks. So the help text prints out:

% iptables -m state -h
[...]
state v0.1.17 options:
 [!] --state state [,state...]
                                State(s) to match
 [!] --fake-ack state [,state...]
                               SYN flood protection: send a faked ACK
                               which answers the SYN-ACK coming from
                               the protected server. BEWARE!
                               It is *counterproductive* with servers having
                               modern stacks! You are warned!

       Possible states are:    INVALID, NEW, ESTABLISHED,
                               RELATED_NEW, RELATED_ESTABLISHED
                               RELATED (_NEW and _ESTABLISHED)