Re: bind() udp behavior 2.6.8.1

From: Kyle Moffett
Date: Tue Dec 14 2004 - 22:21:28 EST


On Dec 14, 2004, at 21:23, Adam Denenberg wrote:
i think you guys are all right. However there is one concern. Not clearing out a UDP connection in a firewall coming from a high port is indeed a security risk. Allowing a high numbered udp port to remain open for a prolonged period of time would definitely impose a security risk which is why the PIX is doing what it does. The linux server is "reusing" the same UDP high numbered socket however it is doing so exactly as the firewall is clearing its state table (60 ms) from the first connection which is what is causing the issue.

I think a firewall ought to be aware of such behavior, but at the same time be secure enough to not just leave high numbered udp ports wide open for attack. I am trying to find out why the PIX chose 60 ms to clear out the UDP state table. I think that is a random number and probably too short of a span for this to occur however i am still researching it.

Any other insight would be greatly appreciated.

60ms is certainly _way_ too small for most UDP traffic. With something like
that, OpenAFS would die almost immediately. I think the current OpenAFS
minimum is like 20 minutes, although somebody patched the OpenAFS
source to send a keepalive every 5 minutes, so it could be reduced. OTOH,
sending a keepalive every 60ms would take a _massive_ amount of
bandwidth even for one client, think about a couple hundred :-D. Heck, I've
even seen pings on a regular basis that take longer than 60ms, which
means that even an infinitely fast kerberos server wouldn't respond quickly
enough :-D.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------


-
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/