North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Providers removing blocks on port 135?
--On Saturday, September 20, 2003 3:36 PM -0400 Sean Donelan <email@example.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.