full-disclosure - SQL Slammer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <9B66BBD37D5DD411B8CE00508B69700F033F2654@pborolocal.rnib.org.uk>
From: John.Airey at rnib.org.uk (John.Airey@...b.org.uk)
Subject: SQL Slammer - lessons learned

> -----Original Message-----
> From: Paul Schmehl [mailto:pauls@...allas.edu]
> Sent: 05 February 2003 15:38
> To: John.Airey@...b.org.uk
> Cc: full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] SQL Slammer - lessons learned
> 
> 
> On Wed, 2003-02-05 at 06:55, John.Airey@...b.org.uk wrote:
> > 
> > How the ports are managed by the ISPs is up to them. We 
> have a managed
> > router where we block everything we can without breaking 
> legitimate access.
> > However, not having a practical option to block certain 
> ports is a problem.
> > My point was on the allocation and use by TCP/IP stacks.
> > 
> Can you think of a legitimate reason why ISPs should allow ports
> 135-139/TCP/UDP to be open to the Internet?  How about port 445/UDP? 
> Many ISPs now block port 25/TCP (for obvious reasons.)  Why not other
> service ports?  What about the ISPs whose policy it is to not allow
> customers to run servers?  Why should they allow any traffic 
> at all from
> the service ports?

Indeed they should, but many don't block them. This is not what I'm talking
about here though.

> 
> > Sure, you can block 1434 udp inbound, but what if your DNS 
> server (that
> > doesn't run SQL server) picks that port randomly for 
> incoming data from
> > other DNS servers? You'll get failures when you shouldn't.
> 
> No, you wouldn't, because DNS servers talk on port 53, and 
> they wouldn't
> negotiate port 1434 because it's reserved for SQL.
> 

Not necessarily. An authoritative server may be listening on port 53, but
use a different port for requests to other DNS servers. This is useful if
you have split-horizon DNS, where the inside servers either cannot or do not
wish to be open to the world on port 53. Some firewalls actually block
inbound UDP to privileged ports, so you have to use higher ports.

Reserved is only true in the port numbers list, not on the implementation of
TCP/IP (which is what I've been getting at all along!). You'll find your
workstation is using "reserved" ports regularly. For example, I've just
connected to a website, and port 3672 was used by my machine, but according
to http://www.iana.org/assignments/port-numbers

lispworks-orb   3672/tcp   LispWorks ORB
lispworks-orb   3672/udp   LispWorks ORB

This was chosen at random. 

I hope you are beginning to understand my point, that you can't just block
individual ports outright without breaking something. This is why you
currently need "stateful" inspection to determine whether the connection to
that port is a response to an internal request or whether it is a request
from outside (ie a SYN,RST or SYN-ACK packet)

- 
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@...b.org.uk 

Am I the only person in the UK who finds it strange that our Prime Minister
complains of Human Rights abuses around the world, yet wishes to opt out of
the European Convention of Human Rights?

- 

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