Providers removing blocks on port 135?

Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/4444 back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we’re hesitent follow their lead.

Adam

Adam Hall wrote:

Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/4444 back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead.

No two networks are the same, nor do they have the same issues. The new RPC exploit worm will be interesting to watch on the above networks if they've dropped their blocks. There's also a question of at which layer they have done so. For example, if blocks were removed from central sites in favor of blocks that were pushed out to the end users.

Allowing the various scans out costs other people money. If nothing else, I'll leave 135 in place long enough to ensure that the number of users that are infected are manageable. My transit customers are all telling me the same thing. They are still pushing it to get people cleaned up and patched. They want their blocks to remain (so they don't have to pay us more).

-Jack

Well, first you would have to find providers willing to say they had ACLs,
then willing to say the ACLs that didn't exist are being removed.

Although 135, 139, 445, etc ACLs still seem to be very wide-spread, they
are not network or service provider wide. It may vary by region,
provider, wholesale arrangement, etc. A provider may have some ACLs in
Atlanta, but not in Boston. Or even in the same city, some circuits may
go through different wholesale arrangements resulting in different ACLs.

FWIW, my opinion is that blocking this at the customer edge per customer
request is fine. Any other blocking by an ISP is damage and should be
routed around like any other internet damage.

Owen

I agree entirely with this. You shouldn't call yourself an ISP unless you
can transport the whole Internet, including those "bad Microsoft ports",
between the world and your customers.

On the other hand, what's a provider to do when their access hardware can't
deal with a pathological set of flows or arp entries? There isn't a good
business case to forklift out your DSLAMs and every customer's matching CPE
when a couple of ACLs will fix the problem. For that matter, there isn't a
very good business case for transporting Nachi's ICMP floods across an
international backbone network when you can do a bit of rate-limiting and
cut your pipe requirements by 10-20%.

Matthew Kaufman
matthew@eeph.com

OK... Obviously, you need to do what you need to do to keep things
running. However, that should be a temporary crisis response. If your
equipment is getting DOS'd for more than a few months, we need to find
a way to fix a bigger problem. Permanently breaking some service (regardless
of what we think of it. Personally, I'll be glad to see M$ go down in flames)
is _NOT_ the correct answer.

Owen

I agree entirely with this. You shouldn't call yourself an ISP unless you
can transport the whole Internet, including those "bad Microsoft ports",
between the world and your customers.

I disagree. In my opinion a NSP shouldn't filter traffic unless one of
its customers requests it. However I strongly believe that an ISP (where
it's customers are Joe Blow average citizen and Susy Homemaker) should
take every reasonable step to protect it's users from malicious traffic
and that includes filtering ports. For example I have no reservation
about NATing basic dialup users. I also have no problem with filtering
ports for services they shouldn't be running on a dialup connection (HTTP,
FTP, DNS) or for services that IMHO have no business on the public
internet (including every single Microsoft port I can identify). To not
do so is IMHO to run a network in an extremely negligent manner.

We do this very thing with email. We filter known malicious messages,
attachments, and spam from email. I don't think there's a reasonable
person among us that can complain about that. Why not do it to network
traffic then? If we should allow every bit of traffic to pass unmolested
by ACLs then we should allow all email to pass by unmolested by anti-virus
and spam checks. It's a two-way street.

On the other hand, what's a provider to do when their access hardware can't
deal with a pathological set of flows or arp entries? There isn't a good
business case to forklift out your DSLAMs and every customer's matching CPE
when a couple of ACLs will fix the problem. For that matter, there isn't a
very good business case for transporting Nachi's ICMP floods across an
international backbone network when you can do a bit of rate-limiting and
cut your pipe requirements by 10-20%.

A good point.

Justin

Well, we could start by having every ISP do what we do, which is to find
worm-infected customers inside our network and get them patched or turned
off. But that's a lot of work. (Especially when you've got a new worm to
track down every week)

The scary/unfortunate part to me is that these things never seem to go
away... Check your web server's log for the last hit from Code Red, for
instance. (6 minutes ago, from 203.59.48.139, on the server I just checked)

Matthew Kaufman
matthew@eeph.com

I agree. In my opinion, at this point, the larger issue that we really need
to find a way to address is to force a recall on the Exploding Pinto and
get real product liability available to the victims. Not just the moron
who bought the Exploding Pinto knowing it would probably explode, who,
actually should have some culpability, but, more importantly, there should
be actual liability on the part of the manufacturer and the reckless
operator to the innocent bystander victims (ISPs, Web sites, etc.) that
are forced to try to repair or work around the damage, handle the traffic,
etc.

The Virus-of-the-week club is not going to go away until somebody gets
a multi-million dollar judgement against Micr0$0ft for the damage inflicted
by their Exploding Pinto, or, until businesses start to see that there
is liability for running unpatched windows systems to the tune of "If you
keep driving your Exploding Pinto, you may have to pay $$$ to the victims
of the explosion when it occurs."

Case 1 will lead Micr0$0ft to start rethinking some of it's less secure
design decisions. Case 2 will lead businesses to evaluate whether
Windows is _REALLY_ a cost effective choice or not.

Until at least one, preferably both of these things happens, we are going
to be stuck with the consequences of other people choosing to run Whine-Doze
whether we run it, or even want to know that anyone runs it or not.

Owen

I disagree. In my opinion a NSP shouldn't filter traffic unless one of
its customers requests it. However I strongly believe that an ISP (where
it's customers are Joe Blow average citizen and Susy Homemaker) should
take every reasonable step to protect it's users from malicious traffic
and that includes filtering ports. For example I have no reservation
about NATing basic dialup users. I also have no problem with filtering
ports for services they shouldn't be running on a dialup connection (HTTP,
FTP, DNS) or for services that IMHO have no business on the public
internet (including every single Microsoft port I can identify). To not
do so is IMHO to run a network in an extremely negligent manner.

Why do you get to decide that, I can't, from a hotel room, call my ISP and
put up a web server on my dialup connection so someone behind a firewall
can retrieve a document I desperately need to get to them? Why _SHOULDN'T_
I run a web server to do this over a dialup connection? Why do you get
to dictate to _ANYONE_ what things they can and can't do with their most
portable internet access? How can you say that it is negligent to refuse
to DOS your customers unless they request it? (blocking traffic to me
that I want is every bit as much a denial of service as flooding my link).

We do this very thing with email. We filter known malicious messages,
attachments, and spam from email. I don't think there's a reasonable
person among us that can complain about that. Why not do it to network
traffic then? If we should allow every bit of traffic to pass unmolested
by ACLs then we should allow all email to pass by unmolested by
anti-virus and spam checks. It's a two-way street.

I leave it to the community to decide whether I am a reasonable person or
not, but, generally, I tend to think that I am viewed as such.
However, I would complain about the parctices you describe above
if I was your customer. If I ask you to filter SPAM, fine. If I ask you not
to filter SPAM, then I should receive every email addressed to me. If I
cannot, then, I won't be your customer. As far as I'm concerned, if an ISP
wants to run anti-virus or spam-checks, they should run them as an opt-in
value added service, _NOT_ as a "we're deleting your mail for you whether
you like it or not" thing.

On the other hand, what's a provider to do when their access hardware
can't deal with a pathological set of flows or arp entries? There isn't

[snip]

A good point.

Yes. I responded to this in a previous post. We must do what we must do
temporarily to keep things running. However, breaking the net is not a long
term solution. We must work to solve the underlying problem or it just becomes
an arms-race where eventually, no services are useful.

Owen

Why do you get to decide that, I can't, from a hotel room, call my ISP and
put up a web server on my dialup connection so someone behind a firewall
can retrieve a document I desperately need to get to them? Why
_SHOULDN'T_
I run a web server to do this over a dialup connection? Why do you get
to dictate to _ANYONE_ what things they can and can't do with their most
portable internet access? How can you say that it is negligent to refuse
to DOS your customers unless they request it? (blocking traffic to me
that I want is every bit as much a denial of service as flooding my link).

The distinction may be blurrier these days, but there *is* a difference
between networking and internetworking. Whereas I'd agree that
interconnections
between networks be unencumbered to the greatest degree possible, the
administrator
of a network can be slightly more draconian in order to keep the network
running
smoothly.

This statement applies, IMHO, to any provider who sells service to
individual
users. It may be a huge wide area dialup network, but it's still a network,
in which the average customer is not a professional network administrator
but
rather a user of indeterminate knowledge level.

Now, if as an ISP you operate an internetwork ("network of networks") and a
network of users, the challenge is obviously how do you draw the distinction
between user/customers and network/customers. I think it's do-able (DHCP
being
one criteria that comes to mind), but there there are a lot of permutations
to
consider.

Owen DeLong wrote:

Yes. I responded to this in a previous post. We must do what we must do
temporarily to keep things running. However, breaking the net is not a long
term solution. We must work to solve the underlying problem or it just becomes
an arms-race where eventually, no services are useful.

I agree, and as a point of fact, many ISP's allow their users to opt out of spam. The ability to opt out of port filtering is a little more difficult, but it is not impossible. Most authentication methods designed have support for telling connection equipment what security lists to use and how to treat a specific user. Some systems, like mine, do not run authentication models that support this, but I consider it very wise to change.

In my case, I will maintain a filter anywhere in the network that it is required in order to help protect the network and the users who rely upon the network. Currently, estimates show that removing port 135 at this junction would allow the current Blaster infected users to become infected with Nachi/Welchia which has more network impact. Some segments, despite blocks, have already had small outbreaks which we had to irradicate. In addition, dialups have very little bandwidth to begin with. The amount of traffic generated on icmp and 135 is currently high enough to severly cripple connectivity on an unprotected dialup account.

I do agree that it is a temporary measure. Yet, one must remember that each network has it's own definitions of temporary, drastic, and appropriate. I now return you to contacting those infected users in your network. :slight_smile:

-Jack