Re: bind() udp behavior 2.6.8.1

[Adam Denenberg]

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.

adam

On Dec 14, 2004, at 5:07 PM, Kyle Moffett wrote:

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