North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Providers removing blocks on port 135?

  • From: Owen DeLong
  • Date: Sat Sep 20 17:51:12 2003



--On Saturday, September 20, 2003 3:36 PM -0400 Sean Donelan <[email protected]> wrote:

Has anyone else notice the flip-flops?

To prevent spam providers should block port 25.


I still disagree with this.  To prevent SPAM, people shouldn't run open
relays and the open relay problem should be solved.  Breaking legitimate
port 25 traffic is a temporary hack.


If providers block ports, e.g. port 135, they aren't providing access to
the "full" Internet.


That would be my position, yes.  Even though I personally have no real use
for that port (other than possibly a honeypot), I think that is true.
Generally, I want my net uncensored by my provider.  If I want them to block
something, I'll tell them.  Otherwise, I expect non-blocking to be the
default.



Should any dialup, dsl, cable, wi-fi, dhcp host be able to use any service
at any time?  For example run an SMTP mailer, or leave Network
Neighborhood open for others to browse or install software on their
computers?


If the person running the system in question chooses to do so, yes, they
should be able to do so.


Or should ISPs have a "default deny" on all services, and subscribers need
to call for permitssion if they want to use some new service?  Should new
services like Voice over IP, or even the World Wide Web be blocked by
default by service providers?


Personally, I'm in the default permit camp with ISPs providing filtration on
demand to customer specs.


As a HOST requirement, I think all hosts should be "client-only" by
default.  That includes things when acting as like hosts such as routers,
switches, print servers, file servers, UPSes.  If a HOST uses a
network protocol for local host processes (e.g. X-Windows, BIFF, Syslog,
DCE, RPC) by default it should not accept network connections.

It should require some action, e.g. the user enabling the service,
DHCP-client enabling it in a profile, clicking things on the LCD display
on the front ofthe printer, etc.


I could live with that, although, having a printer reject LPD by default
doesn't make alot of sense to me.


If the device is low-end and only has a network connection (e.g. no
console), it may have a single (i.e. telnet or web; but not both)
management protocol enabled provided it includes a default password which
can not be discovered from the network (i.e. not the MAC address), is
different for each device (i.e. not predictable), and is only accessiable
from the "local" network (e.g. the "internal" subnet interface).  A
"proprietary" protocol is not an adequate substitute. Static passwords are
inherently insecure if you get enough guesses, so the device should block
use of the default password after N failed attempts until the device is
manually reset.  I recognize this is a potential denial of service, and
for non-default passwords vendors may decide to do something else.  But
if the user hasn't changed the default password; they probably aren't
using it anyway.


I like that idea, although, I don't like saying only one service.  I think
one CLI and one GUI service is reasonable.  I don't want to have to use a
web interface to get to the CLI, and I'm sure a lot of other customers don't
want to know what a CLI is.


SERVICE PROVIDERS do not enforce host requirements.


I REALLY like this.




Owen