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