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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20030209150156.E4050@dx.net.de>
From: steffen at dett.de (Steffen Dettmer)
Subject: SQL Slammer - lessons learned

* Paul Schmehl wrote on Wed, Feb 05, 2003 at 09:38 -0600:
> 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?  

Are that InternetServiceProviders or InternetServiceCensors?

I feel free to implement an own strange private protocol using
UDP 135 and I pay the ISP for routing this. I don't see any
responsibility for ISPs to care about the content.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es tr?gt daher weder Unterschrift noch Siegel.