Full Disclosure mailing list archives
RE: SQL Slammer - lessons learned
From: John.Airey () rnib org uk
Date: Wed, 5 Feb 2003 17:02:06 -0000
-----Original Message----- From: Paul Schmehl [mailto:pauls () utdallas edu] Sent: 05 February 2003 15:38 To: John.Airey () rnib org uk Cc: full-disclosure () lists netsys com Subject: RE: [Full-disclosure] SQL Slammer - lessons learned On Wed, 2003-02-05 at 06:55, John.Airey () rnib org uk wrote:How the ports are managed by the ISPs is up to them. Wehave a managedrouter where we block everything we can without breakinglegitimate access.However, not having a practical option to block certainports 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 DNSserver (thatdoesn't run SQL server) picks that port randomly forincoming data fromother 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 () rnib 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 _______________________________________________ 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 Ron DuFresne (Feb 06)
- Re: SQL Slammer - lessons learned Blue Boar (Feb 06)
- Re: SQL Slammer - lessons learned Ron DuFresne (Feb 06)
- Re: SQL Slammer - lessons learned Blue Boar (Feb 06)
- RE: SQL Slammer - lessons learned Nicob (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 Niels Bakker (Feb 06)
- Re: SQL Slammer - lessons learned Steffen Dettmer (Feb 09)
- Re: SQL Slammer - lessons learned yossarian (Feb 09)
- RE: SQL Slammer - lessons learned Paul Schmehl (Feb 05)
- RE: SQL Slammer - lessons learned Paul Schmehl (Feb 06)
- RE: SQL Slammer - lessons learned Ron DuFresne (Feb 06)
- Re: SQL Slammer - lessons learned Niels Bakker (Feb 07)
- Re: SQL Slammer - lessons learned David Howe (Feb 07)