RE: SQL Slammer - lessons learned

[John.Airey () rnib org uk]

 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.
Read my sentence again. I didn't say that you couldn't reuse a port. I said
you shouldn't insist an IP stack re-use a port.

> > 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?
RFC793 for a start. Even if it was random or sequential assignment, you'd
still need to keep the port "open" to re-use it. ie the resources required
to track all the ports you've ever opened and closed would be prohibitive.
Name me one server that uses port re-use.

> Indeed it would. I am unaware of *any* os that uses random assignment.

Windows 2000 uses random assignment for passive (PASV) mode ftp. However,
I've never been able to get passive mode ftp working. FTP in passive mode is
dangerous in sequential assignment as it is easy to predict the next control
port and hijack the session.

Now please name me one OS that uses sequential assignment from 1024 other
than unpatched Windows 2000 (see
http://support.microsoft.com/default.aspx?scid=kb;en-us;260934). I've seen
evidence of sequential assignment that started at a higher address.

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

Plenty of sites have records that are too big to fit in UDP. Hotmail.com's
MX records for one. If your DNS servers can't use a TCP port, then you can't
email hotmail.com (some would say that isn't a bad thing).

> > ), 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.

Incidentally, if anyone contacts me off the list about this subject (for
example, alleging that UDP is insecure without any evidence), my reply
together with your message will go to the list. 

To re-iterate, I have stated that we either need to separate services from
dynamic port usage OR use stateful filtering (as opposed to outright
blocking). If the former isn't possible, then we need to press vendors to
patch existing TCP/IP stacks to use ports over 49152 for dynamic allocation.


- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender 
immediately and then delete the email and any attachments from your 
system.

RNIB has made strenuous efforts to ensure that emails and any 
attachments generated by its staff are free from viruses. However, it 
cannot accept any responsibility for any viruses which are 
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html