Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: zotob - blocking tcp/445

  • From: Christopher L. Morrow
  • Date: Tue Aug 16 10:37:48 2005


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.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.