Re: zotob - blocking tcp/445
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it. For example: grc.com/su-techzone1.htm scott ----- Original Message Follows ----- From: Gadi Evron <ge@linuxbox.org> To: nanog list <nanog@merit.edu> Subject: zotob - blocking tcp/445 Date: Mon, 15 Aug 2005 21:51:43 +0200
I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works.
Gadi.
On (2005-08-15 18:51 +0000), surfer@mauigateway.com wrote:
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it.
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem.
For example: grc.com/su-techzone1.htm
scott
----- Original Message Follows ----- From: Gadi Evron <ge@linuxbox.org> To: nanog list <nanog@merit.edu> Subject: zotob - blocking tcp/445 Date: Mon, 15 Aug 2005 21:51:43 +0200
I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works.
Gadi.
-- ++ytti
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to.
thanks for that!
There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem.
for we who are under-clued, do you have a url for suggested tools and procedures? thanks! randy
On (2005-08-15 09:28 -1000), Randy Bush wrote:
There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem.
for we who are under-clued, do you have a url for suggested tools and procedures?
www.rommon.com, I'm confident there are others. And some people are using home-baked solutions. Probably plethora (and money) will be one of the bigger problems when deciding to implement this kind of solution. -- ++ytti
In message <17152.60641.317992.429656@roam.psg.com>, Randy Bush writes:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to.
thanks for that!
Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op, o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic o enterprise / site ops can set their users' security policies as that's part of their job and charter randy
On 8/15/05 4:46 PM, "Randy Bush" <randy@psg.com> wrote:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
While its not uncommon to run SMB/Windows file system drive mounts across private WANs, doing so across the Internet, on a non-encrypted tunnel, is the equivalent of running with scissors. I am unaware of any enterprise security folks foolish enough to allow that. Of course, I may be sheltered. (as an aside - running windows file system mounts across enterprise WANs is so common that there are WAN optimization devices that improve remote disk mount performance via protocol spoofing) - Dan
o enterprise / site ops can set their users' security policies as that's part of their job and charter
randy
On Mon, 15 Aug 2005, Daniel Golding wrote:
On 8/15/05 4:46 PM, "Randy Bush" <randy@psg.com> wrote:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
While its not uncommon to run SMB/Windows file system drive mounts across private WANs, doing so across the Internet, on a non-encrypted tunnel, is the equivalent of running with scissors.
no one was arguing that... just like no one argues that riding a motorcycle sans-helmet is stupid (or playing hockey without a helmet)
I am unaware of any enterprise security folks foolish enough to allow that. Of course, I may be sheltered.
'enterprise security folks' are probably not the issue... The fact remains that lots of folks DO do this :( There are quite a few folks between 'consumer' and 'enterprise' that do all manner of dumb things on the Internet (where 'dumb' is equivalent to running smb shares across the public network minus encryption/ipsec). It's their choice to do that, and their network providers are expected/demanded to pass those packets for them. -Chris
While its not uncommon to run SMB/Windows file system drive mounts across private WANs, doing so across the Internet, on a non-encrypted tunnel, is the equivalent of running with scissors.
yep. agree. but, as it does not damage the track, and only opens the runner to harm, as the track maintainer, it's not mine to legislate against it.
I am unaware of any enterprise security folks foolish enough to allow that.
i suspect there are risk-takers and fools out there and we just happen not to know them. randy
Randy Bush wrote:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to.
thanks for that!
Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
o enterprise / site ops can set their users' security policies as that's part of their job and charter
randy
I actually agree with you Chris and Steven. Point is though, that in a HUGE outbreak - sometimes you might even have to cause a self-DDoS and kill some of your services to parts of your networks or at all, to keep your net alive, not to mention secure. As immediate critical measures, blocking tcp/445 might be an acceptable solution. Nobody is talking about censoring the Internet. I believe that blocking port 445 is Good, just like I believe it will not get done by most and for Good reasons. Every solution has its good applications - sometimes short-term, even Bad long term solutions. Thing is, how do they remain temporary rather than becoming perm.? Gadi.
On Tue, 16 Aug 2005, Gadi Evron wrote:
Randy Bush wrote:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to.
thanks for that!
Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
o enterprise / site ops can set their users' security policies as that's part of their job and charter
randy
I actually agree with you Chris and Steven. Point is though, that in a HUGE outbreak - sometimes you might even have to cause a self-DDoS and kill some of your services to parts of your networks or at all, to keep your net alive, not to mention secure.
This decision (to block port X or not in a large outbreak) is still a network by network decision... Smaller or 'more tightly bound' networks might have an easier time making that call, I'd bet that almost all of the very large networks will look at each case and come to the same conclusion: 1) our network isn't affected by this problem 2) our customers will be affected by a block 3) our customers should deal with security on their own, unless they are paying for service which includes said blocking.
As immediate critical measures, blocking tcp/445 might be an acceptable solution. Nobody is talking about censoring the Internet.
see above. and recall that there were several respondents to this thread that were talking exactly about blocking tcp/445 to their customers, or on their network, which is censoring. The distinction Randy, and I and Steve, are making is that: 1) each network should decide on their own 2) each person deciding should understand the ramifications of that decision 3) each person deciding should keep in mind that they might not understand all of their customers requirements for traffic.
I believe that blocking port 445 is Good, just like I believe it will not get done by most and for Good reasons.
'good' 'in the right situation' which isn't 'across the network as a whole'. Oh, do the current spate of tcp/445 problems also exist in the new netbios of tcp/80 incarnations MS has cooked up? I'd venture to guess they probably do... wanna block tcp/80 as well? :)
Every solution has its good applications - sometimes short-term, even Bad long term solutions. Thing is, how do they remain temporary rather than becoming perm.?
From the Slammer incident we learned that blocking 1434 for even a short
This last sentence is a long and hard learned lesson :) Once you block port X and people figure that out, they expect you to always block port X. They drop their guard and focus on other problems, they have a new 'firewall' :( it's you. period of time made people complaicant. They didn't patch their broken servers/systems until we unblocked the traffic and they got re-infected again :( Do not become the internet firewall for your large customer base... it's bad.
[snip arguments]
Do not become the internet firewall for your large customer base... it's bad.
Okay, so please allow me to alter the argument a bit. Say we agreed on: 1. Security is THEIR (customers') problems, not yours. 2. You are not the Internet's firewall. That would mean you would still care about: 1. You being able to provide service. 2. Your own network being secure (?) In a big outbreak, not for the WHOLE Internet, I'd use whatever I can. It can easily become an issue of my network staying alive. Blocking that one port then might be a viable solution to get a handle on things and calm things down. Naturally though you are right again, it is a case-by-case issue and can not be discussed in generalities. Gadi.
At 12:46 AM 8/16/2005, Christopher L. Morrow wrote:
On Tue, 16 Aug 2005, Gadi Evron wrote:
Randy Bush wrote:
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to.
thanks for that!
Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
o enterprise / site ops can set their users' security policies as that's part of their job and charter
randy
I actually agree with you Chris and Steven. Point is though, that in a HUGE outbreak - sometimes you might even have to cause a self-DDoS and kill some of your services to parts of your networks or at all, to keep your net alive, not to mention secure.
This decision (to block port X or not in a large outbreak) is still a network by network decision... Smaller or 'more tightly bound' networks might have an easier time making that call, I'd bet that almost all of the very large networks will look at each case and come to the same conclusion: 1) our network isn't affected by this problem
And when it is, or parts of it are, then it IS time to take measures. When SQL Slammer came out, we were using a facility owned by your employer. We weren't infected, and had blocked all such traffic at our border. However, the 65xx switch belonging to the facility, and upstream of our systems there, was dropping 10% of our traffic because it could not keep up with the UDP traffic from other customers fed through that same switch. In that instance, you blocked the SQL Slammer traffic. It still wasn't affecting your network per se, but was seriously impacting other customers. Blocking was the right action in that case.
2) our customers will be affected by a block 3) our customers should deal with security on their own, unless they are paying for service which includes said blocking.
This has to be balanced against whether the absence of the block prevents other customers from getting the services they are paying for. It's a balance, not an absolute. There's also the issue of billing to consider. If the attack traffic drives up the costs for customers on metered (burstable) bandwidth, and you could have stopped that by a few responsive blocks elsewhere in your network, is it ethical to allow that traffic to flow and run up the bill? Unless the customer has some way to request remote blocks, that can be a significant concern.
As immediate critical measures, blocking tcp/445 might be an acceptable solution. Nobody is talking about censoring the Internet.
see above. and recall that there were several respondents to this thread that were talking exactly about blocking tcp/445 to their customers, or on their network, which is censoring.
Or saving everyone's time, money and headaches. The interpretation depends a great deal on where you sit.
The distinction Randy, and I and Steve, are making is that: 1) each network should decide on their own 2) each person deciding should understand the ramifications of that decision 3) each person deciding should keep in mind that they might not understand all of their customers requirements for traffic.
Absolutely agree with all of these. That still doesn't point at a decision to never block. Just as during the initial SQL Slammer outbreak, one must balance the desire to not filter anything against the desire to keep customers (especially those who are effectively innocent bystanders) from losing service.
I believe that blocking port 445 is Good, just like I believe it will not get done by most and for Good reasons.
'good' 'in the right situation' which isn't 'across the network as a whole'. Oh, do the current spate of tcp/445 problems also exist in the new netbios of tcp/80 incarnations MS has cooked up? I'd venture to guess they probably do... wanna block tcp/80 as well? :)
Every solution has its good applications - sometimes short-term, even Bad long term solutions. Thing is, how do they remain temporary rather than becoming perm.?
This last sentence is a long and hard learned lesson :) Once you block port X and people figure that out, they expect you to always block port X. They drop their guard and focus on other problems, they have a new 'firewall' :( it's you.
From the Slammer incident we learned that blocking 1434 for even a short period of time made people complaicant. They didn't patch their broken servers/systems until we unblocked the traffic and they got re-infected again :(
If you hadn't blocked 1434 during Slammer, you would have had many customers who were not infested exceptionally pissed because some networking equipment was falling over. So, do you just degrade service for all customers because a few are idiots? Or do you replace the faulty network equipment that could not handle the load (in the case of slammer, it was switch gear that could pass packets at wire speed, but couldn't handle the flow creation/cleanup rate). I don't recall the switches being replaced to solve that situation.
Do not become the internet firewall for your large customer base... it's bad.
And don't let one of your customers spew at a rate that then hammers the rest of your customers to the point where their Internet connectivity is non-functional, or they'll go buy their connectivity elsewhere. This makes the decision structure much more complex, as it must be. This issue isn't as clear cut as some would try to make it. Dan
On Tue, 16 Aug 2005, Daniel Senie wrote:
At 12:46 AM 8/16/2005, Christopher L. Morrow wrote:
On Tue, 16 Aug 2005, Gadi Evron wrote:
Randy Bush wrote:
>I'm not nearly confident enough to decide on behalf of almost >billion other people how they should benefit from the Internet >and how not to.
thanks for that!
Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
as i just replied to a private message from an enterprise op,
o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic
o enterprise / site ops can set their users' security policies as that's part of their job and charter
randy
I actually agree with you Chris and Steven. Point is though, that in a HUGE outbreak - sometimes you might even have to cause a self-DDoS and kill some of your services to parts of your networks or at all, to keep your net alive, not to mention secure.
This decision (to block port X or not in a large outbreak) is still a network by network decision... Smaller or 'more tightly bound' networks might have an easier time making that call, I'd bet that almost all of the very large networks will look at each case and come to the same conclusion: 1) our network isn't affected by this problem
And when it is, or parts of it are, then it IS time to take measures.
sure, each network operator needs to see if their network is affected by the event, if so fix it, if not think hard about 'fixing' it...
When SQL Slammer came out, we were using a facility owned by your employer. We weren't infected, and had blocked all such traffic at our border. However, the 65xx switch belonging to the facility, and upstream of our systems there, was dropping 10% of our traffic because it could not keep up with the UDP traffic from other customers fed through that same switch.
yes, and we fixed that with local filters, not global ones. and yes, 6500's with routing+switching suck.
In that instance, you blocked the SQL Slammer traffic. It still wasn't affecting your network per se, but was seriously impacting other customers. Blocking was the right action in that case.
it did affect equipment in some places, 6500's being one of them :(
2) our customers will be affected by a block 3) our customers should deal with security on their own, unless they are paying for service which includes said blocking.
This has to be balanced against whether the absence of the block prevents other customers from getting the services they are paying for. It's a balance, not an absolute.
a local balance... yes. make the decision for your network. I get vocal about this particular topic because there are folks on this (and other) lists who are not as experienced as you or randy or others who have spoken up. They may read the posts as: "I should be blocking tcp/445" and then run off and do that... It's dangerous to talk about this in generic terms, saying: "ZoTob came out and crushed my datacenter 6500 infrastructure, the only thing I could do was drop tcp/445 inbound from customers inside the datacenter on each 6500!" is more specific and more useful, imho.
There's also the issue of billing to consider. If the attack traffic drives up the costs for customers on metered (burstable) bandwidth, and you could have stopped that by a few responsive blocks elsewhere in your network, is it ethical to allow that traffic to flow and run up the bill? Unless the customer has some way to request remote blocks, that can be a significant concern.
I think most folks would treat that as: "Show me how much your 95th percentile changed and we'll adjust the bill"
As immediate critical measures, blocking tcp/445 might be an acceptable solution. Nobody is talking about censoring the Internet.
see above. and recall that there were several respondents to this thread that were talking exactly about blocking tcp/445 to their customers, or on their network, which is censoring.
Or saving everyone's time, money and headaches. The interpretation depends a great deal on where you sit.
The distinction Randy, and I and Steve, are making is that: 1) each network should decide on their own 2) each person deciding should understand the ramifications of that decision 3) each person deciding should keep in mind that they might not understand all of their customers requirements for traffic.
Absolutely agree with all of these. That still doesn't point at a decision to never block. Just as during the initial SQL Slammer outbreak, one must balance the desire to not filter anything against the desire to keep customers (especially those who are effectively innocent bystanders) from losing service.
agreed, that's part of the decision... but it has to be clear that that decision is locally grown and thought through very, very thoroughly.
Do not become the internet firewall for your large customer base... it's bad.
And don't let one of your customers spew at a rate that then hammers the rest of your customers to the point where their Internet connectivity is non-functional, or they'll go buy their connectivity elsewhere. This makes the decision structure much more complex, as it must be. This issue isn't as clear cut as some would try to make it.
yes, the not-so-clear-cut part was the point of my posting back about this.
On Mon, 15 Aug 2005, surfer@mauigateway.com wrote:
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it.
rule #1: do not be the Internet's Firewall rule #2: see rule #1 a leaf network can make any decisions they want on traffic filtering, large ISP's should probably not do this as there are invariably people out there that will want SNMP/ICMP/NetBIOS/SQL-NameService to work over their WAN link(S). I recall some 'fun' with this issue on: 1) slammer worm (ms has a developers thingy that REQUIRES 1434 to work over the internet) 2) welchia/nachi - how can I ping monitor my remote sites? ymmv.
For example: grc.com/su-techzone1.htm
scott
----- Original Message Follows ----- From: Gadi Evron <ge@linuxbox.org> To: nanog list <nanog@merit.edu> Subject: zotob - blocking tcp/445 Date: Mon, 15 Aug 2005 21:51:43 +0200
I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works.
Gadi.
Chris, This isn't directed at you, just adding my 2 cents to the thread ... On Aug 15, 2005, at 3:29 PM, Christopher L. Morrow wrote:
On Mon, 15 Aug 2005, surfer@mauigateway.com wrote:
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it.
rule #1: do not be the Internet's Firewall rule #2: see rule #1
That should definitely be on a T-shirt. :-)
a leaf network can make any decisions they want on traffic filtering, large ISP's should probably not do this as there are invariably people out there that will want SNMP/ICMP/NetBIOS/SQL-NameService to work over their WAN link(S). I recall some 'fun' with this issue on:
1) slammer worm (ms has a developers thingy that REQUIRES 1434 to work over the internet) 2) welchia/nachi - how can I ping monitor my remote sites?
ymmv.
Leaf network filtering (or not) is largely solved. Keep in mind, some SP's sell "Managed Security Services," which may be PE- or CE- based firewalls, but run by the SP on behalf of the customer. If the customer cares enough, then ask and/or pay the SP to block the traffic they don't want, only on their access circuit(s). Presumably, the SP will figure out a model for the service to both instantiate and maintain the filter(s) as well as recoup costs for backhauled bits that get dropped at, or near, the doorstep of the CE. (Note, the word "model" could mean an additional charge above & beyond basic access or it may be included as part of basic access -- it all depends on how much work, sophistication in filtering, etc. occurs as well as what the market can bear). In this case, one size (a.k.a.: filtering) does not (easily) fit all ... -shane
On Mon, 15 Aug 2005 20:05:30 MDT, Shane Amante said:
Leaf network filtering (or not) is largely solved.
Ahem. :) If this was a "solved" problem, we'd not be having a thread about a zotob worm. There's a *very* large gap between "the clued know of a range of suitable solutions" and "the great unwashed have deployed appropriate solutions".
On Tue, 16 Aug 2005 Valdis.Kletnieks@vt.edu wrote:
On Mon, 15 Aug 2005 20:05:30 MDT, Shane Amante said:
Leaf network filtering (or not) is largely solved.
Ahem. :)
If this was a "solved" problem, we'd not be having a thread about a zotob worm.
thank you.
though http://www.rommon.com/sandbox.html looks to be a commercial product (and hence the spawn of evil:-), has anyone got success/failure stories? it looks to speak directly to this issue. randy
Well, I guess blocking is a good idea. That is why censoring was invented in the first place. Blocking port 25, Simple Mail Transfer, makes sense. If nobody can send emails then nobody can send spam. Ok let us block port 25 provocatively. :) Blocking port 137, NETBIOS Name Service, ok I am running linux. I dont need NETBIOS. I think it makes sense keeping windows out of the internet. Without windows there is no spam, no virus, no worm. Yes, let us block. Blocking port 138, NETBIOS Datagram Service, see above. Block it! Blocking port 139, NETBIOS Session Service, see above. Who needs windows? It is a security risk in the first place. Blocking port 445, Microsoft-DS, if it is from Microsoft it is always good blocking it. I have forgotten port 80, World Wide Web HTTP, and port 53, Domain Name Server. I know for shure windows does use them. Lets block them! Without poisoned homepages you cannot be tricked to download vermin in the first place. So it is a very good idea to block port 80. Without DNS viruses might have difficulties finding their seed servers. Yes it is a MUST. We absolutely must block port 53 :) Firewall rules ============== They are poison! Every rules takes time to process. Every rules makes router, your firewall your whateveryoulike crawl more slowly. Why not block port 1 right through port 1023? There is no reason why anybody but a hacker might need them. Where to block? =============== After seeing what to block we need to find the right place where to block. ISPs and carriers and, ..., live from selling the complete internet. They get money for what they dont block. There is no reason why they should block anything. Me? I am running linux mostly. I do use port 137 for ssh - only fools do use port 22. Ever seen you could download Cassels Dictionary plus the Bible by simply listening to port 137? So please dont block port 137 for me. And please dont block port 138 - I need it for ftp from some not so secure machines running Phyton :) Windows users? Oh yes - we have found it! Just unpluck every windows pc and we will have no more reason for blocking anything. If you really want your windows pc to peek into the internet use a firewall. Use a HARDWARE firewall and best block all ports from 1 to 1023. You never know :) In germany we have the fastest higways of he world and we drive the fastest cars. We need to drive fast because of the many holes in the streets, to glide over them. But in our cities we are not allowed to drive fast because the streets have become a childrens playground. The internet has become a childrens playground too. It does not make sense to develop faster and faster internet access. 4800 baud is too fast for children. Let us get back to 110 and best only allow machines with paper output and punched tape copy for everything to have a proof for the judge - in case they need it against us. Have a nice weekend - Oh, sorry I did not think we only had tuesday! Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: peter@peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason
Christopher L. Morrow wrote:
On Mon, 15 Aug 2005, surfer@mauigateway.com wrote:
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it.
rule #1: do not be the Internet's Firewall rule #2: see rule #1
Surely we realize that this discussion is not concerning the oft repeated "Internet's Firewall" debate. Its about containing a potential worm/virus outbreak. Call it a network wide quarantine. The damages inflicted by worms/viruses in the past that we have all seen and are still coping with (C&C reports anyone?) are well known. This is network self preservation. Otherwise the garbage will eventually suffocate us all. Apples and oranges.
Joe Maimon wrote:
This is network self preservation. Otherwise the garbage will eventually suffocate us all.
It's like cancer initially was treated with drugs and equipment which did serious damage to the whole body, killing many in the process and today the methods are much more targeted to the actual bad tissue while minimizing collateral damage. Port blocking is like cancer treatment from the 1980's. Pete
On Tue, 16 Aug 2005, Joe Maimon wrote:
Christopher L. Morrow wrote:
On Mon, 15 Aug 2005, surfer@mauigateway.com wrote:
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it.
rule #1: do not be the Internet's Firewall rule #2: see rule #1
Surely we realize that this discussion is not concerning the oft repeated "Internet's Firewall" debate.
This is network self preservation. Otherwise the garbage will eventually suffocate us all.
and again I point to the above rules. What your network can't handle 'scanning wise' is completely different from what the network I work on can handle. If your network is being jeopardized by some level of scanning they fix that, but that is a local decision. Blindly stating "large isps filter port X" is just disingenuous, there are certainly cases as exceptions, most of which end with the ISP in question saying: "Wow that was a lot more painful than we thought originally:("
The sky is falling, or never mind. AV vendor press releases are always amusing to read. http://news.com.com/Zotob+worm+finds+its+path+limited/2100-7349_3-5833777.ht... As of Monday morning on the West Coast, the original Zotob.A had infected about 50 computers worldwide, and the first variant, Zotob.B, had compromised about 1,000 systems, the antivirus software maker said.
and again I point to the above rules. What your network can't handle 'scanning wise' is completely different from what the network I work on can handle.
If your network is being jeopardized by some level of scanning they fix that, but that is a local decision. Blindly stating "large isps filter port X" is just disingenuous, there are certainly cases as exceptions, most of which end with the ISP in question saying: "Wow that was a lot more painful than we thought originally:("
I've been following the "don't be the Internet's firewall" thing, but I lost you now. Quarantine works. Sorry, it does. If your network can handle everything, that's great. I have seen cases where people blocked entire countries for mitigation purposes, not to mention entire ISP's. Is that wise and/or good? It worked for them for the time. The point is reacting to a given situation. A reason not to do something would NOT be "because then people will not patch". I am sorry. Nobody is arguing that the philosophy is bad. We even agree with you. Where I strongly disagree is canceling this method out on ANY level, because that's just plain wrong. It's simple, it works, and yesterday it worked for several "big ISP's". Would these ISP's generally block port 445? How is that relevant? They just prevented their entire user-base from getting infected and their network from being DDoS'd and soon after becoming a DDoS source, by going the KISS way and reacting. Gadi.
Surely we realize that this discussion is not concerning the oft repeated "Internet's Firewall" debate. Its about containing a potential worm/virus outbreak. Call it a network wide quarantine.
surely you realize that this discussion is not about civil rights and the constitution, but about combatting terrorists. randy
Randy Bush wrote:
Surely we realize that this discussion is not concerning the oft repeated "Internet's Firewall" debate. Its about containing a potential worm/virus outbreak. Call it a network wide quarantine.
surely you realize that this discussion is not about civil rights and the constitution, but about combatting terrorists.
To a level, it is. Is combating terrorists bad? No one here would say no. Then it starts getting complicated when you discuss the HOW. Over-protecting by first saying "no" because you fear potential "how's" is silly. Fearing the HOW itself is legitimate. Not every block is a censor, m'kay? Some censors are good - do you want to see kiddie porn on TV? Let us not make this a freedom of speech argument and go back to network issues. You have say, 35K clients who will get infected in the next 2 days if you don't block port 445. Are you going to block it or are you going to let them get infected and infect others? That or I am missing something. Gadi.
On 8/16/05, Gadi Evron <ge@linuxbox.org> wrote:
Randy Bush wrote:
Surely we realize that this discussion is not concerning the oft repeated "Internet's Firewall" debate. Its about containing a potential worm/virus outbreak. Call it a network wide quarantine.
surely you realize that this discussion is not about civil rights and the constitution, but about combatting terrorists.
To a level, it is.
Is combating terrorists bad? No one here would say no. Then it starts getting complicated when you discuss the HOW.
Over-protecting by first saying "no" because you fear potential "how's" is silly.
Fearing the HOW itself is legitimate.
Not every block is a censor, m'kay? Some censors are good - do you want to see kiddie porn on TV? Let us not make this a freedom of speech argument and go back to network issues.
You have say, 35K clients who will get infected in the next 2 days if you don't block port 445. Are you going to block it or are you going to let them get infected and infect others?
What if you are a transit provider that serves ebay, yahoo, and/or google and the worm is propogating over TCP port 80? If they have sufficient bandwidth and security mechinisms to protect themselves I can guarantee you that those enterprise customers would not want their upstream provider unilaterally dropping the traffic. I recognise that the service we are talking about here is typically used in file sharing but people may even be using 445 for different services (as silly as it sounds). Where will the filtering end? Is your NSP/ISP responsible for filtering virii, spam, phishing? I'm not saying it wouldn't be nice, but considering the types of attacks we see coupled with the fact that many enterprise customers are service providers themselves, providing service to yet other service providers, it is very difficult to take their decission making power away.
That or I am missing something.
Gadi.
On Aug 17, 2005, at 11:03 PM, routerg wrote:
What if you are a transit provider that serves ebay, yahoo, and/or google and the worm is propogating over TCP port 80?
No one is suggesting that anyone suspend reason when making a decision to temporarily, or permanently for that matter, block packets with a specific port setting. It is a unreasonable stretch to imagine a transit provider, serving Ebay, Yahoo, and/or Google, who will have a staff unreasonable enough to block TCP/80 to halt a virus from spreading.
Where will the filtering end?
The "slippery slope" defense has never stood in logical arguments, I don't understand why it should stand anywhere else. Once again, no on is asking anyone to suspend reason when making decisions. No on is making the statement "You must block ports used by virii of any magnitude, permanently without thought or investigation.". It was suggested that for outbreaks of significant size and severity, networks should issue temporary blocks on ports with little legitimate use. Expanding that suggestion to encompass more is being disingenuous to the original intent of the suggester
Is your NSP/ISP responsible for filtering virii, spam, phishing?
ISPs are held accountable by their customers, whether rightfully or wrongfully, for virii, spam, and phishing. Customers expect their ISP to investigate, filter, and otherwise secure their connection. We are held accountable for the traffic we source. I feel comfortable exercising some caution with traffic which is destined to me, especially if it is going to create an issue where other networks will hold me accountable for the fallout. As someone eluded to earlier in the thread, customers expect to receive the traffic they want, and they expect their provider to prevent that which they did not request. Problems, support calls, and differences of opinion happen on the edge where those desires are not codified.
On 8/18/05, James Baldwin <jbaldwin@antinode.net> wrote:
On Aug 17, 2005, at 11:03 PM, routerg wrote:
What if you are a transit provider that serves ebay, yahoo, and/or google and the worm is propogating over TCP port 80?
No one is suggesting that anyone suspend reason when making a decision to temporarily, or permanently for that matter, block packets with a specific port setting. It is a unreasonable stretch to imagine a transit provider, serving Ebay, Yahoo, and/or Google, who will have a staff unreasonable enough to block TCP/80 to halt a virus from spreading.
I was only trying to make the point that it would be extremely disruptive for enterprise class providers to filter ports all over the place, regardless of the port number. Today, the carrier class providers are meant to proivde a routing interface to the network.
Where will the filtering end?
The "slippery slope" defense has never stood in logical arguments, I don't understand why it should stand anywhere else. Once again, no on is asking anyone to suspend reason when making decisions. No on is making the statement "You must block ports used by virii of any magnitude, permanently without thought or investigation.". It was suggested that for outbreaks of significant size and severity, networks should issue temporary blocks on ports with little legitimate use. Expanding that suggestion to encompass more is being disingenuous to the original intent of the suggester
Is your NSP/ISP responsible for filtering virii, spam, phishing?
ISPs are held accountable by their customers, whether rightfully or wrongfully, for virii, spam, and phishing. Customers expect their ISP to investigate, filter, and otherwise secure their connection.
I would agree with this if we are talking about consumer markets. Most cable/DSL providers have policies in place so that their customers don't use the consumer class services to offer services, in which case this type of mitigation is acceptable. However, I've only ever seen a handfull of requests from enterprise class customers wanting their network provider to filter spam on their behalf. Usually they just want DoS attack traffic stopped upstream. They don't want their provider monitoring the contents of their packets.
We are held accountable for the traffic we source. I feel comfortable exercising some caution with traffic which is destined to me, especially if it is going to create an issue where other networks will hold me accountable for the fallout.
As someone eluded to earlier in the thread, customers expect to receive the traffic they want, and they expect their provider to prevent that which they did not request. Problems, support calls, and differences of opinion happen on the edge where those desires are not codified.
On 8/18/05, James Baldwin <jbaldwin@antinode.net> wrote:
On Aug 17, 2005, at 11:03 PM, routerg wrote:
What if you are a transit provider that serves ebay, yahoo, and/or google and the worm is propogating over TCP port 80?
No one is suggesting that anyone suspend reason when making a decision to temporarily, or permanently for that matter, block packets with a specific port setting. It is a unreasonable stretch to imagine a transit provider, serving Ebay, Yahoo, and/or Google, who will have a staff unreasonable enough to block TCP/80 to halt a virus from spreading.
I was only trying to make the point that it would be extremely disruptive for enterprise class providers to filter ports all over the place, regardless of the port number. Today, the carrier class providers are meant to provide a routing interface to the network.
Where will the filtering end?
The "slippery slope" defense has never stood in logical arguments, I don't understand why it should stand anywhere else. Once again, no on is asking anyone to suspend reason when making decisions. No on is making the statement "You must block ports used by virii of any magnitude, permanently without thought or investigation.". It was suggested that for outbreaks of significant size and severity, networks should issue temporary blocks on ports with little legitimate use. Expanding that suggestion to encompass more is being disingenuous to the original intent of the suggester
Is your NSP/ISP responsible for filtering virii, spam, phishing?
ISPs are held accountable by their customers, whether rightfully or wrongfully, for virii, spam, and phishing. Customers expect their ISP to investigate, filter, and otherwise secure their connection.
I would agree with this if we are talking about consumer markets. Most cable/DSL providers have policies in place so that their customers don't use the consumer class services to offer services, in which case this type of mitigation is acceptable. However, I've only ever seen a handful of requests from enterprise class customers wanting their network provider to filter spam on their behalf. Usually they just want DoS attack traffic stopped upstream. They don't want their provider monitoring the contents of their packets.
We are held accountable for the traffic we source. I feel comfortable exercising some caution with traffic which is destined to me, especially if it is going to create an issue where other networks will hold me accountable for the fallout.
As someone eluded to earlier in the thread, customers expect to receive the traffic they want, and they expect their provider to prevent that which they did not request. Problems, support calls, and differences of opinion happen on the edge where those desires are not codified.
Randy Bush <randy@psg.com> wrote: [...]
surely you realize that this discussion is not about civil rights and the constitution, but about combatting terrorists.
And we have always been at war with Eastasia. -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key /:.*posting.google.com.*/HX-Trace:+j
participants (19)
-
abuse＠cabal.org.uk -
Christopher L. Morrow -
Daniel Golding -
Daniel Senie -
Florian Weimer -
Gadi Evron -
James Baldwin -
Joe Maimon -
My Name -
Peter Dambier -
Petri Helenius -
Randy Bush -
routerg
-
Saku Ytti -
Sean Donelan -
Shane Amante -
Steven M. Bellovin -
surfer＠mauigateway.com -
Valdis.Kletnieks＠vt.edu