[prev in list] [next in list] [prev in thread] [next in thread]
List: netfilter-devel
Subject: Re: Handling Port-Unreachable Response to UDP
From: Tim Burress <tim () variosecure ! net>
Date: 2003-07-29 4:04:08
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic