at Friday, February 07, 2003 11:47 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> was seen to say: >> -----Original Message----- >> From: David Howe [mailto:[EMAIL PROTECTED]] >> Sent: 07 February 2003 11:09 >> To: [EMAIL PROTECTED] >> Subject: Re: [Full-Disclosure] SQL Slammer - lessons learned >> >> >> at Friday, February 07, 2003 10:11 AM, [EMAIL PROTECTED] >> <[EMAIL PROTECTED]> was seen to say: >>> Like I said, the probability of it affecting you is 64,511/1 per DNS >>> query. >> Hmm. not exactly - its a bit more complex. if you block port 'n', >> then the (n-1024)th time a program requests a random port (assuming >> it is running no services on ports between 1024 and 'n') it should >> be assigned >> it. > Not at all. Neither a DNS server or a workstation will assign a > "privileged" port dynamically. It's still 64,511/1 that it > dynamically assigns the port you block. The probability goes down the > more ports you block. Ideally 49152 onwards would be used for dynamic > allocation, but they aren't. That would require that dynamic ports are allocated randomly - but they aren't. they are allocated sequentially by the os starting at 1025, so port 1050 is almost guaranteed to be hit within ten minutes of a reboot.....
> There's no reason to insist an IP stack would re-use it ever. Fairly common - particularly in download managers and/or multthreaded ftp clients. what will normally happen is that the controller app will start one or more worker threads - each one of which will obtain one or two ports, and request from the controller app a task (a specific download). Because it is inefficient to release those ports then request another from the os, they don't - they simply re-use the ports (ideally in the case of ftp retaining the control channel intact) until they are shut down. The IP stack isn't insisting on *anything* - the programs are simply performing their tasks as programmed. > In fact, the only way to reuse a port under a random assignment > system would be to leave it open, which breaks the RFCs. what RFC does port re-use break? and just how long has every server on the planet been breaking it? > I think you are making this up. A random assignment (which is what is > required to prevent attacks coming back through open ports) would > take any of the ports above 1024. Indeed it would. I am unaware of *any* os that uses random assignment. > Even if what you are saying is > true, the effects of what I am saying would be far worse. I've just > checked our email server, and it appears to be using ports > sequentially for outgoing mail. The ports are currently over 35,000. > It's been up a couple of days, as I installed a new kernel recently > (ie Sendmail on Linux) yep, that is common for a server. for a user workstation typically shut down at night? ports below 2000 are almost guaranteed to be used once per day, ports above 65,000 usually have no chance at all of usage. > It's the recursive resolution that is the issue here (with UDP > blocking). In some cases these have to use a different "source" port > for queries to a "destination" udp port 53. Remember too that > oversized queries (larger than a UDP packet) will come back on a tcp > port. That's interesting - about time I reread the RFCs then, as i thought tcp was only used for zone transfers. > Which brings me back to the point. Either every IP stack is rewritten > to use the alleged "dynamic range" only (unlikely but it may be fixed > with IPv6. I haven't looked as my ISP won't connect us to the "6bone" > anyway) Not a problem - plenty of places will allow you dial-in access to the 6bone using 6over4. IIRC all recent linuxen are compiled in for that, and the Win2K support is bunded into XP. > ), or you block SYN, RST and SYN-ACK (ie step 4, figure 7 of > RFC793) from the outside for TCP and block the creation of UDP > connections from the outside. That is what "stateful inspection" does. Interesting sidebar - IE will attempt a "quick connect" to IIS servers by not doing the usual SYN/SYN+ACK/ACK sequence. from the outside this looks like an attempt to ACKscan :) _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
