Re: Handling Port-Unreachable Response to UDP

[Tim Burress <tim@variosecure.net>]

Henrik Nordstrom wrote:

>mån 2003-07-28 klockan 15.52 skrev Tim Burress:
>
>  
>
>>We've been looking at a problem in which a client sends a UDP packet to 
>>a server on an unused port. This generates an ICMP port-unreachable 
>>packet (as usual), but we find that this same ICMP packet can then be 
>>replayed back to the client over and over. Apparently it gets through 
>>netfilter because our standard rules allow RELATED traffic.
>>    
>>
>
>Explain the context of "replayed back to the client over and over".
>
In a test of one of our systems, an engineer set up a scenario in which 
a client and server machine were connected via a firewall running 
iptables/netfilter. The client sends a UDP packet to an unused port on 
the server, and the server responds with ICMP port-unreachable. This 
packet is captured on the server side and then replayed back to the 
client machine, passing safely through the firewall until the conntrack 
associated with the original UDP "session" times out. Thus there are 
really two issues, (1) the fact that multiple ICMP error messages pass 
through in response to single "stimulus" packet, and (2) the fact that 
replayed packets are getting through at all. We need to investigate the 
second issue further, but the first one prompted some discussion. We 
seem to be in a gray area since (as far as we know) there are no 
standards governing how sessions consisting entirely of connectionless 
protocols should respond to ICMP error messages. It seemed like deleting 
the conntrack record for the UDP session might be worthwhile because it 
closes off the possibility of flooding the client with ICMP error 
messages, but it sounds like people are more concerned about the 
overhead of setting up and tearing down conntrack records if the client 
sends multiple UDP packets.

We're curious enough about this to benchmark it, though, so I was just 
wondering what the proper procedure is to destroy a conntrack record. I 
see several entrypoints in ip_conntrack_core.c that look promising, but 
it's hard to tell what calls what sometimes when function pointers are 
embedded in structures. Is it enough just to call destroy_conntrack() or 
do we need to call clean_from_lists() first? Or is there a better way? 
I'm not yet clear on how the data structures relate to each other.

Thanks for your replies!

Tim