Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: bind() udp behavior 2.6.8.1 | Date | Tue, 14 Dec 2004 17:07:28 -0500 |
| |
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/
| |