Providers removing blocks on port 135?

Sat Sep 20 21:46:33 UTC 2003



--On Saturday, September 20, 2003 3:36 PM -0400 Sean Donelan 
<sean at donelan.com> 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