|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: zotob - blocking tcp/445
At 12:46 AM 8/16/2005, Christopher L. Morrow wrote: And when it is, or parts of it are, then it IS time to take measures.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 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. 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.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. 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. Or saving everyone's time, money and headaches. The interpretation depends a great deal on where you sit.> > 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. 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.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. 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.> 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 :( 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.Do not become the internet firewall for your large customer base... it's bad. Dan
|