Re: bind() udp behavior 2.6.8.1
From: Kyle Moffett (mrmacman_g4_at_mac.com)
Date: 12/14/04
- Previous message: Jim Nelson: "[PATCH] Documentation/kernel-docs.txt update."
- In reply to: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Next in thread: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Reply: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 14 Dec 2004 17:07:28 -0500 To: Adam Denenberg <adam@dberg.org>
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Jim Nelson: "[PATCH] Documentation/kernel-docs.txt update."
- In reply to: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Next in thread: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Reply: Adam Denenberg: "Re: bind() udp behavior 2.6.8.1"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
