Handling Port-Unreachable Response to UDP

Handling Port-Unreachable Response to UDP

[Tim Burress]

Hello!

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.

We're wondering if an appropriate response to this situation would be to 
destroy the conntrack entry for the UDP connection after receiving the 
first port-unreachable? It seems like such a change would improve the 
strength of netfilter-based firewalls, while adding only a little bit of 
overhead when/if the client retries sending to the same UDP port several 
times. What do people think of this idea? Is there any reason not to do it?

Thanks!

Tim

Re: Handling Port-Unreachable Response to UDP

[Henrik Nordstrom]

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".

> We're wondering if an appropriate response to this situation would be to 
> destroy the conntrack entry for the UDP connection after receiving the 
> first port-unreachable?

Sounds reasonable to me, but may as you said cause a significant load
impact on connntrack if this client floods you...

-- 
Henrik Nordstrom <hno@marasystems.com>
MARA Systems AB

Re: Handling Port-Unreachable Response to UDP

[Maciej Soltysiak]

> > We're wondering if an appropriate response to this situation would be to
> > destroy the conntrack entry for the UDP connection after receiving the
> > first port-unreachable?
>
> Sounds reasonable to me, but may as you said cause a significant load
> impact on connntrack if this client floods you...
Hmm, how about having a configurable amount of UDP related ICMPs for
retransmision handling, then destroying the conntrack entry.
If we're flooded the packets will not get matched after some threshold
(say 3), and possible retransmissions will get through.

Regards,
Maciej

Re: Handling Port-Unreachable Response to UDP

[Henrik Nordstrom]

On Mon, 28 Jul 2003, Maciej Soltysiak wrote:

> Hmm, how about having a configurable amount of UDP related ICMPs for
> retransmision handling, then destroying the conntrack entry.
> If we're flooded the packets will not get matched after some threshold
> (say 3), and possible retransmissions will get through.

Isn't that sort of what we have today (a short timeout after ICMP 
unreachable)

Regards
Henrik

Re: Handling Port-Unreachable Response to UDP

[Tim Burress]

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

Re: Handling Port-Unreachable Response to UDP

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Tim" == Tim Burress <tim@variosecure.net> writes:
    Tim> We're wondering if an appropriate response to this situation would
    Tim> be to  
    Tim> destroy the conntrack entry for the UDP connection after receiving
    Tim> the first port-unreachable? It seems like such a change would
    Tim> improve the strength of netfilter-based firewalls, while adding only
    Tim> a little bit of overhead when/if the client retries sending to the
    Tim> same UDP port several times. What do people think of this idea? Is
    Tim> there any reason not to do it? 

  Yes, you are opening yourself up to a trivial DoS via ICMP.
  Like we need to give people more reasons to think they should drop ICMP.

  The best choice is to do nothing - it is really up to the application
to decide if it should pay attention to the ICMP port unreachable or keep
trying, assuming it will get through eventually.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBPyVNJYqHRg3pndX9AQFgiQQAhOTbxlHdDT+hsB+9CE8Uf/IuGvCgkUY2
6d9wQvZDiaE3EB9jBlrvTyHbArzAGH2USsShfxr2Zi4ke/0Eq6wOzQbX6r4NX4c4
Sny+iw2ZQjwueWMDwNYgfb2gjNuc12anjXC991qV158IJBUoqH9GMaDETMjEGP/a
IF2IjTzqD1s=
=KsDD
-----END PGP SIGNATURE-----