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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1044459487.15689.29.camel@utd49554.utdallas.edu>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: 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?

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

-- 
Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/~pauls/
AVIEN Founding Member


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ