Re: bind() udp behavior 2.6.8.1

[Adam Denenberg <adam@dberg.org>]

i am aware that UDP is connectionless.  However in terms of a firewall
this is different.  It _must_ keep a state table of some sorts otherwise
high port outbound connections destined for a DNS server will never be
let back in b/c the firewall will just say "Why is this dns server
making a udp connection to port 32768 on this client?".  Keeping a state
table allows this behavior thru the firewall as it should.

My issue is that linux is not randomizing or incrementing the ports it
uses for udp connections to prevent this sort of issue since udp is
connectionless.  We dont have sequence numbers or the sorts like TCP to
sort this out, we only have source ip and port.

Other OS's seem  to do this and thus apps are not getting broken when
connections are made thru the firewall, which is why i originally posted
the question.  I was hoping that maybe there is some workaround or that
hopefully someone else encountered this issue.  I am not saying the
firewall is not totally to blame, but i can see why it is behaving the
way it is when seeing tons of connections from the same udp ip/port come
in.

thanks again
adam



On Tue, 2004-12-14 at 12:10, Jan Engelhardt wrote:
> >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