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
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.htmlas 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
>
>>>> 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.htmlas 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 traffico enterprise / site ops can set their users' security policies
as that's part of their job and charterrandy
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.
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.?
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
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.
>
> 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
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'>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
> >
> > 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 problemAnd 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.