This is the first trade publication I've seen that's covered some
of the issues with ISPs blocking or not blocking ports.
Port blocking last resort in fight against virus
Long term problems can be caused by port blocking
by Paul Brislen and James Niccolai, Auckland and San Francisco
http://computerworld.co.nz/webhome.nsf/UNID/BEC6DE12EC6AE16ECC256D8000192BF7!opendocument
"While some end users are calling for ISPs to block certain ports relating
to the Microsoft exploit as reported yesterday (Feared RPC worm starts to
spread), most ISPs are reluctant to do so."
Sean Donelan wrote:
http://computerworld.co.nz/webhome.nsf/UNID/BEC6DE12EC6AE16ECC256D8000192BF7!opendocument
"While some end users are calling for ISPs to block certain ports relating
to the Microsoft exploit as reported yesterday (Feared RPC worm starts to
spread), most ISPs are reluctant to do so."
Is it just me that feels that blocking a port which is known to be used to perform billions of scans is only proper? It takes time to contact, clean, or suspend an account that is infected. Allowing infected systems to continue to scan only causes problems for other networks. I see no network performance issues, but that doesn't mean other networks won't have issues.
-Jack
Is it just me that feels that blocking a port which is known to be used
to perform billions of scans is only proper?
the second, and important part of the, question is whether there
are legitimate packets to that port which want to cross your border.
for 135, i am not aware of any that should cross my site's border
un-tunneled.
randy
Is it just me that feels that blocking a port which is known to be used
to perform billions of scans is only proper? It takes time to contact,
clean, or suspend an account that is infected. Allowing infected systems
to continue to scan only causes problems for other networks. I see no
network performance issues, but that doesn't mean other networks won't
have issues.
I have two faces, let's hear what they say:
"I am a network operator. I do not see issues with my network unless
somebody fills it up beyond capacity. Then I might ask somebody a
question as to why they are shoveling so many more packets than
usual. If it is a panic, I might null0 someone. I just want to keep
my network transparent."
"I am a systems administrator. Sometimes, there are security problems with
my operating systems of choice. Then, I fix those hosts that are affected,
and all is well. The network is not bothering me as long as it is
transparent."
Your chosen path is a down-turning spiral of kludgey dependencies,
where a host is secure only on some nets, and some nets can't cope
with the load of all administrative filters (some routers tend to
take port-specific filters into slow-path). That way lies madness.
IMHO it's a prudent security measure to disallow access to the Windows
ports 135,137-139,445, etc. from the Internet at large. We block these
ports at the edge, with exceptions for the very few customers who ask
for it (generally customers using Exchange who don't know how to
properly deploy it across the Internet).
So we block, but we make exceptions. Not that restrictive, and not that
hard.
-Bob
Mans Nilsson wrote:
Your chosen path is a down-turning spiral of kludgey dependencies,
where a host is secure only on some nets, and some nets can't cope
with the load of all administrative filters (some routers tend to
take port-specific filters into slow-path). That way lies madness.
Secure? Who's talking about secure? I'm talking about trash. Not blocking the port with a large group of infected users means that your network sends trash to other people's networks. Those networks may or may not have capacity to mean your network's trash.
Temporarily blocking 135 is not about security. A single infection within a local net will infect all vulnerable systems within that local net. A block upstream will not save local networks from cross infecting. However, it does stop your network from sending the trash out to other networks which may have smaller capacities than your network does.
Of course, perhaps a good neighbor doesn't really care about other people's networks? Perhaps there is no such thing as a good neighbor. It's kill or be killed, and if those other networks can't take my user's scanning them, then tough!
There is legitimate traffic on 135. All users I've talked to have been understanding in a short term block of that port. They used alternative methods. I have a lot of valid traffic still cranking out the other Microsoft ports.
-Jack
There is legitimate traffic on 135. All users I've talked to have been
We started blocking 135-139 and 445 a week ago... we got one complaint,
and added an exception for those two ip addresses (one remote/one local).
We're just a small regional ISP, but we've seen little real use
of these ports by our customers across the 'net. This is a good thing.
and you are willing to open holes across your network for every tom, dick
or sally that wants to share files with their pal across town? (or off
your network)
If people want to use the network they need to take the responsibility and
patch their systems. Blocking should really only be considered in very
extreme circumstances when your network is being affected by the problem,
or if the overall threat is such that a short term network-wide block
would help get over the hump.
Christopher L. Morrow wrote:
If people want to use the network they need to take the responsibility and
patch their systems. Blocking should really only be considered in very
extreme circumstances when your network is being affected by the problem,
or if the overall threat is such that a short term network-wide block
would help get over the hump.
Correct, and that's what I consider this; a short term network-wide block that would help get over the hump. While my network is stable, that doesn't mean everyone being scanned is stable. There are undoubtably DOS conditions caused by this worm.
-Jack
Each local network should make this decision on their own, the backbone
should really only get involved if there is a real crisis. The local
network has the ability to determine if the ports/protocols are being used
legitimately, not the backbone. Just cause you'd have to be insane to use
MS shares over the open internet doesn't mean there aren't people doing it
(or selling Exchange mailboxes over it too apparently?).
So, if in YOUR network you want to do this blocking, go right ahead, but I
wouldn't expect anyone else to follow suit unless they already determined
there was a good reason for themselves to follow suit. As an aside, a day
or so of 5 minutely reboots teaches even the slowest user to find a
firewall product and upgrade/update their systems, eh?
Just a note that my manager Anand Lal is quoted in the article, he's said
that the quotes attributed to him are not correct.
We have put some port 135 blocks in however, probably only for a short
amount of time.
I've been looking at out traffic graphs and trying to decide if traffic
really is down 10-15% over the last 24 hours or it's just my imagination.
I've been looking at out traffic graphs and trying to decide if traffic
really is down 10-15% over the last 24 hours or it's just my imagination.
I would say 5-10% below where it should be taking into account seasonal
variations, it�s within the error margin, but barely.
Pete
Christopher L. Morrow wrote:
So, if in YOUR network you want to do this blocking, go right ahead, but I
wouldn't expect anyone else to follow suit unless they already determined
there was a good reason for themselves to follow suit. As an aside, a day
or so of 5 minutely reboots teaches even the slowest user to find a
firewall product and upgrade/update their systems, eh?
Yeah. I hate to admit it, but there is a lot gained from this worm. The of the worm will secure a lot of systems from other exploits of the same vulnerability which can be used for much worse. From what I've seen, a lot of networks have sent user's to custom webpages to assist in patching and removal of the worm. I wonder if microsoft minds the redistribution of patches in this senario. 
My outbound ratio of worm to total packets has decreased to 7%. Helpdesk call volume has increased drastically, but we expect things to be close to normal by end week.
As a side note, I think one of my peers issued a 135 block in their core (haven't checked). The inbound scan numbers should be much higher than they are.
-Jack
Who should determine what protocols can cross your site's border router?
You or your ISP (ignoring the fact a lot of people on this list are their
own ISP)?
80% or more of customers wouldn't notice if you blocked everything on
their connection except HTTP/HTTPS and DNS. So why do ISPs let all
the other infection laden protocols reach their customers?
Fix spam - block port 25
Fix Slammer - block port 1434
Fix Blaster - block port 135
Fix KaZaA - block everything
I think filters/firewalls are usefull. I believe every computer should
have one. I have several. I just disagree on who should control the
filters.
in your opinion who should control them? (just curious)
Sean, All
Watching this thread I can't resist a question if ISPs would see any use
for automated propagation of information to be filtered/blocked to all
of their (and possibly) neighbours border routers ?
I am sure you have noticed my & Pedro's recent draft:
draft-marques-idr-flow-spec-00.txt
Just checking for possible feedback of interested ISPs if any on this
one ... The example listed in the draft is targeted to address DDoS, but
the concept is equally applicable to virus fights as well.
Thx,
R.
bellovin et al. have shown that the signaling protocol needs to convey
far more characterization than you propose.
randy
That is fine. The amount of information to be carried is easily
extensible. So if you can help us to determine the required fields we
will be more then glad to add them.
R.