zotob - blocking tcp/445

Tue Aug 16 13:02:58 UTC 2005

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