Re: bind() udp behavior 2.6.8.1

From: Jan Engelhardt
Date: Tue Dec 14 2004 - 12:14:31 EST


>any firewall must keep some sort of state table even if it is udp. How

No.

>else do you manage established connections? It must know that some high

You don't manage something that does not need managing. It's like firing a
bullet at some. You can not tell whether there's still more bullets to come or
not.

>numbered port is making a udp dns request, and thus be able to allow
>that request back thru to the high numbered port client b/c the
>connection is already established.

See linux-os's reply. UDP is connectionless.

>what does any fireawall do if it sees one ip with the same high numbered
>udp port make a request in a _very_ short amount of time (under 60ms for
>this example)?

I let it pass.

>It must make a distintion between an attack and legit
>traffic.

That's something VERY different. There is a difference between **knowing**
that a set of packets _are related_ to each other and the time between two
**arbitrary** packets.

> So if it sees one ip/port make multiple requests in too short
>of a time frame, it will drop the traffic, as it probably should.

Depends on the definition of attack. Look it at that way:

localhost:32768 sends an UDP packet to dnsserver:53... but already the next
packet CAN BE malicious. (Another process can take over the port if the former
has dropped the socket.)

>This
>is causing erratic behavior when traffic traverses the firewall b/c the

Then fix the FW.

>linux kernel keeps allocating the same source high numbered ephemeral

In your case, the socket is allocated once for the whole program. This socket
is _reused_.

>port. I would like to know if there is a way to alter this behavior b/c
>it is breaking applications.

No, as said, your FW is broken.




Jan Engelhardt
--
ENOSPC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/