Re: bind() udp behavior 2.6.8.1

[Kyle Moffett]

On Dec 14, 2004, at 12:01, Adam Denenberg wrote:
> any firewall must keep some sort of state table even if it is udp.  How
> else do you manage established connections?  It must know that some 
> high
> 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.
>
> 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)?  It must make a distintion between an attack and legit
> traffic.  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.  This
> is causing erratic behavior when traffic traverses the firewall b/c the
> linux kernel keeps allocating the same source high numbered ephemeral
> port.  I would like to know if there is a way to alter this behavior 
> b/c
> it is breaking applications.

When I wrote my user-space UDP over TCP tunneling software, I combined
the Internal IP and port and the External IP and port into a single 
hashed
value that I used as an index into my "psuedo-connection" hash, of which
each entry referenced an index in my 2000 item "pseudo-connection" 
table.
For each packet from an unrecognized host, I added a new hash entry and
table entry, then forwarded the packet.  When I get a new packet 
matching
an old-but-not-expired rule, I set the "last_seen" value to the current 
time.
When a connection is 5 minutes since "last_seen", then it can be removed
if there is pressure on the table, otherwise it will accept packets 
until it is
1 hour old, at which point it gets purged.  I've found that this system 
works
well at tunneling everything from Kerberos and OpenAFS to DNS without
problems.  Given that this relatively simple piece of sofware is able to
successfully manage a multitude of UDP connections, I would suggest
that an advanced connection-tracking firewall like yours has serious 
bugs
if it can't perform equally well.  Either that or it shouldn't be 
meddling in the
affairs of such UDP packets.

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/