Full Disclosure mailing list archives
Re: SQL Slammer - lessons learned
From: "David Howe" <DaveHowe () gmx co uk>
Date: Fri, 7 Feb 2003 17:52:43 -0000
at Friday, February 07, 2003 11:47 AM, John.Airey () rnib org uk <John.Airey () rnib org uk> was seen to say:
-----Original Message----- From: David Howe [mailto:DaveHowe () gmx co uk] Sent: 07 February 2003 11:09 To: John.Airey () rnib org uk Subject: Re: [Full-disclosure] SQL Slammer - lessons learned at Friday, February 07, 2003 10:11 AM, John.Airey () rnib org uk <John.Airey () rnib org uk> 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
Current thread:
- Re: SQL Slammer - lessons learned, (continued)
- Re: SQL Slammer - lessons learned yossarian (Feb 09)
- RE: SQL Slammer - lessons learned John . Airey (Feb 05)
- RE: SQL Slammer - lessons learned Cushing, David (Feb 05)
- RE: SQL Slammer - lessons learned Paul Schmehl (Feb 05)
- RE: SQL Slammer - lessons learned John . Airey (Feb 06)
- RE: SQL Slammer - lessons learned Paul Schmehl (Feb 06)
- RE: SQL Slammer - lessons learned Ron DuFresne (Feb 06)
- RE: SQL Slammer - lessons learned Paul Schmehl (Feb 06)
- RE: SQL Slammer - lessons learned John . Airey (Feb 07)
- Re: SQL Slammer - lessons learned Niels Bakker (Feb 07)
- Re: SQL Slammer - lessons learned David Howe (Feb 07)
- Re: SQL Slammer - lessons learned Niels Bakker (Feb 07)
- Re: SQL Slammer - lessons learned David Howe (Feb 07)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- Re: SQL Slammer - lessons learned Georgi Guninski (Feb 09)
- Re: SQL Slammer - lessons learned yossarian (Feb 09)
- RE: SQL Slammer - lessons learned Steve Wray (Feb 09)
- RE: SQL Slammer - lessons learned Schmehl, Paul L (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- RE: SQL Slammer - lessons learned Steve Wray (Feb 09)
- Re: SQL Slammer - lessons learned Helmut Springer (Feb 09)
- RE: SQL Slammer - lessons learned John . Airey (Feb 10)
- RE: SQL Slammer - lessons learned John . Airey (Feb 10)
(Thread continues...)